Comments 167
Смотрел лекцию Владимира Пирожкова — это дизайнер (конструктор?) автомобилей, долгое время проработавший за рубежом. Он говорил, что надо обращать внимание на тенденции, чтобы понять, каким будет будущее. Тенденции с компьютерами заключатся в том, что системные блоки стремительно сжимаются, в то время, как мониторы не менее стремительно растут в ширину и высоту, становясь при этом всё тоньше.
В недалёком будущем, скажем, через 10-15-20 лет легко представить, что компьютер будет похож ни лист ватмана формата А4 или А3. Мы будем его сворачивать, носить с собой, раскладывать на столе, работать.
Понятно, что в таком виде мышь клавиатура будут не очень адекватными средствами ввода. Скорее всего, у нас будут жесты и голос.
Я могу представить, как на таком компьютере смогут работать дизайнеры или музыканты. Даже, возможно, авторы текстов. Но программисты?
Не знаю, какими будут языки программирования будущего, но, кажется, что они будут именно визуальными. Я пытался подобрать удачные примеры визуальных языков и у меня получился список, похожий на тот, что в статье. Мой список был поменьше, потому что я не настолько в теме. Тем не менее, конечные автоматы, разнообразные деревья и ER-диаграммы у меня были.
Блок-схемы в этот список не попали: я никогда не считал их удобными или удачными.
Я заметил, что удачные языки по своей природе декларативны, и это довольно предсказуемо. Думаю, что новая форма компьютеров вынудит нас переходить на визуальные языки и программировать жестами и голосом. Скорее всего, визуальные языки будут именно декларативными. Но пока конкретных вариантов я не видел.
Простите, куда системные блоки сжимаются (причем аж даже стремительно)? они как были коробкой на литров 30-40-50. так и остались со времен IBM-PC (или даже раньше), ток раньше клали горизонтально, а теперь чаще вертикально (на столе, под столом)
Да есть поделия китайцев и тайваньяцев довольно компактные и на ноутбучном железо. Но это вот именно что по сути ноутбук, только урезанный по функционалу
Как ни старайся, а 4090 (да хоть 4060) не особо сожмешь
Почему тайваньцев и китайцев? Маломерные форм-факторы — это международные стандарты. Я видел мини-системники производства HP и Dell, не говоря уже об эппловских Mac mini.
Мне кажется, вы хватаетесь за отдельные исключения, совершенно игнорируя то, что я написал — тенденцию. Не надо вам в футурологи.
Почему тайваньцев и китайцев?
у одних есть платформа декс-мини, у других компы, которые помещаются на ладоне
а что такое "маломерные форм-факторы" ?
мини-системники с задушенным i3 - ну да, они продаются (в период пандемии на авито их продавали дешево, потому что компании их покупали, но люди не пользовались в силу возможно убогости и низкой производительности, буквально за 16к можно было купить какой-то "мин-системник" с i3 9-го поколения, но с индексом t, у которого все достаточно грустно по производительности), но это ж не значит, что их вообще покупают за пределами офисов. Вы бы себе купили бы сознательно десктоп, где производительность зарезана, при наличии альтернативы? если да. то зачем?
Не надо вам в футурологи
да я как-то не стремился
Если Вы считаете, что есть какой-то тренд, то его надо цифрами потверждать, а то у меня значит "единичные случаи" (ага, игровые видюхи то миллионами продают, ну очень исключительные случаи), а у Вас - тренды
Ну вот я написал про Mac Mini, вы успешно мой пример проигнорировали. Кажется, просто не влезает в ваше представление о мире.
Я довольно давно отказался от тауэров, лет десять назад. Собирал себе и системники небольшие, сейчас вот на ноутах сижу. Работаю, пишу программы, всё ок.
Тренды не надо подтверждать цифрами. Я тут никому ничего не доказываю, я просто размышляю. Кажется, этот навык уже утрачивает свою актуальность.
вот я написал про Mac Mini
ни маки, ни какая-то отдельная модель (мак-мини) не занимает какого-то доминирующего положения на рынке PC. Поэтому я проигнорировал
не влезает в ваше представление о мире
какие-то странные попытки задеть
Собирал себе и системники небольшие, сейчас вот на ноутах сижу
ну и я собирал и и ноут у меня тоже есть и что? единичный опыт это вообще ни разу не репрезентативно. А ноуты это вообще не "системные блоки"
Тренды не надо подтверждать цифрами
Правда что ли? то есть вот это
Тенденции с компьютерами заключатся в том, что системные блоки стремительно сжимаются
это просто "Миш, мне пофиг, я так чувствую"
Да, правда. Потому что, я напишу ещё раз — мне интересна тема визуальных языков программирования, мне интересно, как это могло бы выглядеть. И да, идея о том, что такая проблематика перед нами встанет, появилась у меня, когда я увидел, как звукорежиссёр одной группы, на концерте которой я был, ходил по залу с планшетом и настраивал звук.
Я подумал: а кто ещё может работать на планшете? А мы, программисты, сможем ли?
Мой комментарий для тех, кому интересно подумать в эту сторону. Вам не интересно. Хорошо. Давайте больше не отнимать друг у друга время.
Отвечу Вам так - все смотрят на свои (редко - чужие) проблемы со "своей колокольни"! И, когда Вы увидели как звукорежиссёр управлять звуком с планшета - так - лет так 30-35 назад (ещё со школьной скамьи), увлекаясь и программированием и сочинение музыки, чертыхался от музыкальных редакторов от Cakewalk, Cubase, Sound forge до только набирающих тогда популярность мультидорожечников, от Sony Acid (который нынче Vega) до... (уже не помню какие тогда уже были, вроде тоже Sound Forge и Audition - но он он тогда по-другому назывался). Нет - в те времена я тащился от Cakewalk и Acid, а затем и от Fruty Loops - но считал это всё слишком неудобным и примитивным! И именно тогда мне пришла в голову мысль - что писать музыку куда удобнее было бы текстом (а тогда среди программирования также были крайне популярны визуальные среды разработки как Delphi, Vusual C, Borland C++ builder, или, скажем, Dream viewer; даже азы данных в СУБД стремились рисовать в визуальных конструкторах)!
И я стал думать - как это всё лучше организовать - перебрав несколько отличных концепций! Считая себя 100; оригинальным новатором этой темы! Особенно на фоне того - как в XXI веке музыка стали сочинять генеративные AI сети - генерировать музыку текстом для них самое то!
И только спустя 30 лет - я узнал о том, что программирование музыки придумали на заре самого программирования 3-го поколения - т.к. в 70-х когда прошлого века! Кстати, там начинали, кажется, именно с графического программирования (сейчас не помню, на вскидку какой это был ЯП - поищу)! Но... ознакомившись с ними всеми... в т.ч. с недавнопояшившишься новым ЯП для создания музыки, базирующемся на JavaScript - счёл это всё примитивным и не удобным!
И сейчас проектирую свой собственный ЯП для создания музыки под рабочим названием "Orange". Это будет весь продвинутый ЯП - не только для композирования и аранжировки - но и для сложной звукорежиссуры и звуковой обработки, и даже аконкурирования с системами библиотек цифровых музыкальных инструментов - а-ка Kontakt (который я тоже счёл крайне примитивным) и реализации гипер-мультисемплирования! Но всё делает текстом (само собой работа с привычными для музыкантов и звукорежиссёров средствами ввода тоже подразумевается - даже с, условно с электрогитарами и аналоговыми источниками звука") - и всё через кодогенерацию (само собой информации - это цифровые RAW данные).
И не только статичное программирование - но и динамичное - когда музыка меняется прям в реальном времени!
И управление этим всем подразумевается не только специфической адаптированной структурой текстовых скриптов! Но и реализацией адаптированной студии IDE (для повышения удобства) - с продвинутой частью визуализации! И конечно же поддержкой плагинов и библиотек! И... само собой версионирование а-ля Git, и продвинутого текстового поиска (в т.ч. по регулярным выражениям), анализа, маккро/мето-программирования, кодогенерации и рефакторинга!
И да.... моя идея не в том, чтобы управлять этим с планшета - это достаточно сложная система (особенно при управлении в реальном времени) - для работы с которой могут потребоваться несколько мониторов и лаже клавиатур... не считая специфичного музыкального оборудования! Но... в относительно простых статичных случаях можно обойтись и, условно, рядовыми текстовыми процессорами с несколькими специальными плагинами для комфорта! Да и при желании - частично можно было бы и с планшета управлять!
Так что вот даже так - музыка - это тоже код - и его вполне себе можно писать программой! Как и всё в нашем мире - есть программный кол! Таков мой девиз!
А системы искусственного интеллекта тут станут отличными помощниками с их гибким восприятием и оперированием текстовыми данными!
Это вот прямо интересно. Никогда не думал про кодирование музыки. Мне казалось, что формат MIDI закрыл эту проблематику, но я никогда не погружался глубоко.
Сам формат бинарный, но, если мне не изменяет память, есть текстовое представление?
И, да, есть классическое графическое представление — ноты.
А есть какие-то статьи или видео про ваши наработки?
MIDI (Musical Instrument Digital Interface) как формат данных - это бинарное представление просто последовательности инструкций (команд). Дефакто стандарт цифрового сопряжения любого музыкального оборудования или программных плагинов (кроме прямой обработки звука в виде потока декретированной волны, хотя и WAVE тоже через MIDI обрабатывать можно). В каком-то смысле - можно считать это аналогом IR в контексте управляемых ЯП. Только туго с управляемыми ЯП для MIDI. Про текстовую нотацию для MIDI не слышал - но можно глянуть LilyPond
Про различные музыкальные нотации вот тут wiki (английская версия полнее). Но распространены сейчас табулатуры и ABC-разметка - текстовый программный подход к музыки позволяет применять разные нотации - как будет удобно! У меня есть о свой расширение для табулатур!
А любителям графической визуализации предлагаю заглянуть сюда
А адептам моделирования разметкой - сюда
А есть какие-то статьи или видео про ваши наработки?
Статья, как и сам ЯП пока в разработке ;-)
Но для удовлетворения любопытства - вот несколько отрывков из зеро-драфт:
Пролог ORANGE Music creator studio
OMC Language - это спецификация скриптовой языка программирования, разработанного для написания музыкальных (или иных других) звуковых композиций, да и вообще для звукоизвлечения и обработке звука. Это специфический ЯП для эффективной работы со звуком, в первую очередь с его молодикой – т.е. главная поставленная задача – лёгкость аранжировки (от того и название orange – arrange) музыкального полотна плюс наложение эффектов и мультидорожечный (мультиканальный) мастеринг, с глубокой автоматизацией всех процессов. С поддержкой применения сторонних плагинов (в т.ч. VST) и внешнего звукового процессинга. С полным описанием всего проекта в удобочитаемом и набираемом текстовом виде. Впрочем, обработка звука тут не 100% обязательна, и на данном ЯП вполне себе можно писать практически любые программы (подключив необходимые библиотеки).
Данный ЯП является высокоуровневым, практически строго императивным, языком с элементами функционального программирования, и в своей базе является интерпретируемым.
Спецификация прицельно разработана для удобного программирования многопоточного потока команд исполнения (каждый трек – это отдельный параллельный поток) и их синхронизации друг с другом; причём во многих случаях операторы неявно (или явно) порождают отдельный поток (трэк) исполнения (но этим можно управлять по контексту использования). Так же ЯП является контекстно-зависимым - в каждый момент есть некое состояние текущего контекста исполнения, им можно гибко управлять, настраивая общие контекстные параметры, на которые могут опираться исполняемые в нём команды, контекст можно клонировать и дробить (в подблоках и подпрограммах), делать частично наследуемым, сохранять, создавать новый и восстанавливать для текущего потока, и передавать в другие потоки и подпрограммы.
ЯП может эффективно применяться как для статического написания музыки (или иного процесса, но деле всё-таки будет идти речь о музыке), так и для динамического создания (или сведения) музыки в реальном времени, в т.ч. через внешнюю генерацию другими алгоритмами и управления воспроизведением, например, для программ-автогенератором музыки, как полностью автономных (нейросети, самостоятельно сочиняющие музыку), так и более простые алгоритмы – которые просто генерируют динамически меняющийся звуковой поток по заданным правилам реакции на какие-либо состояния их собственных процессов (или отслеживаемых ими внешних процессов). В принципе, на OMC тоже можно было бы реализовать в будущем полностью автономную генерацию музыки – у ЯП нет каких-либо ограничений для этого.
Введение в команду sample
Для помещения в текущий трек содержимого нужно просто выполнять разные встроенные, библиотечные, кастомные команды и паттерны. С точки зрения программирования всё это будет очень похоже просто на императивный (с элементами функционального стиля) код, где каждый трек – это просто параллельный поток исполнения программы, но с некоторыми специфическими нюансами.
Например, чтобы воспроизвести какой-то семпл (считаем, что он заранее уже был загружен программно, или входит в часть ресурсов проекта) нужно выполнить команду
sample(“путь\имя семпла”)
Можно создать переменную-псевдоним для этой команды, чтобы получить более короткое имя
val a = @sample(“путь\имя семпла”)
И далее просто обращаться к ней
a a a a //Семпла прозвучит подряд 4 раза друг за другом
Такие алиасы можно создавать для любых выражений Языка (в т.ч. параметрических и с открытым концом – об этом всё будет подробнее позже рассказано), но выражение должно иметь полностью закрытые скобки, которые были открыты в нём.
Существует много путей управления воспроизведением семплов и их последовательности, например, если надо вставить задержку между ними – то есть команда delay
a delay(100ms) a delay(100ms) a delay(100ms) a delay(100ms)
команда sample имеет параметр для установки начальной и конечной задержки
var a = @sample(“путь\имя семпла”, BeginDelay=40ms, EndDelay=60ms)
a a a a
или так
var a = @{ delay(40) sample(“путь\имя семпла”) delay(60) }
a a a a
Команда sample имеет очень много параметров, и вообще – для воспроизведения сложных семплов могут быть определены отдельные специальные функции. Сейчас я не буду это всё рассматривать. Но несколько важных рассмотрю
Одним из главных параметров является тон
sample(“путь\имя семпла”, .D) //Формально тон «Ре» - если семпл откалиброван по тону «До»=C); в действительности – это изменение тона семпла от базового на 3 ноты вверх; формально – понятие ноты тут тоже условно (семпл может быть сконфигурирован произвольным образом) – и это просто изменение на 3 тона вверх
sample(“путь\имя семпла”, .+D) //Но 3 тона и октаву вверх (октавы формально тоже условны)
sample(“путь\имя семпла”, .--D) //Опустить тон на 2 октавы и увеличить на 2 тона
sample(“путь\имя семпла”, .-<D) //Опустить тон на одну октаву и 3 тона
sample(“путь\имя семпла”, 800) //Числами тоже можно задавать: положительные – увеличение тона, отрицательные – уменьшения относительно базы
sample(“путь\имя семпла”, .D, BaseToneOffset=800) //Можно так же дополнительно смещать базовый тон, относительно которого будет воспроизводиться заданный основной тон
sample[“путь\имя семпла”].BaseToneOffset=800 //А вот так можно изменить значение по умолчанию для семпла (только в рамках текущего трека); замечу, что имя ресурса задано в квадратных скобках
Помимо тона важным параметром является длительность звучания:
sample(“путь\имя семпла”, .A, 500ms) //Базовый тон, звучит полсекунды (важно, чтобы он сэмпл не был короче 500 мс или был зациклен)
Тут для разных форматов семплов очень много нюансов определения длительности их звучания – и у команды sample есть много параметров для корректного использования длительности. Например, у семпла может быть часть затухания (после основного звучания) и в примере выше длительность будет общая т.е. вместе с затуханием. Если же нужно не учитывать длительность затухания то можно написать так:
sample(“путь\имя семпла”, .A, 500ms, FadePlay=.Always) //Если звучание не уложится в 500 мс, то затухание всё-равно будет проиграно
или так
sample(“путь\имя семпла”, .A, MainLen=500ms) //аналогично – лимитируется только длина основной части семпла
sample(“путь\имя семпла”, .A, 750ms MainLen=500ms) //Основная часть семпла лимитируется 500 мс, а весь семпл (с затуханием) лимитируется 750 мс
sample(“путь\имя семпла”, .A, 500ms, FadePlay=.Continue) //Затухание будет полностью звучать, если успеет начаться за 500 мс проигрывания всего семпла
И так далее – тут возможностей очень много. Особенно для циклических семплов. Для удобства проигрывания сложных семплов луче пользоваться специальными библиотечными командами, более узко специализированными для воспроизведения семпла в том или ином режиме. Плюс применять псевдонимы для перенастроенных вызовов команд.
Но ещё одним важным параметром длины семпла является DelayLen – это длина задержки семпла
sample(“путь\имя семпла”, .A, 750ms DelayLen=500ms) //Формально семпл будет звучать 750 мс, но выполнение sample завершится уже через 500 мс и начнётся выполнение следующей команды, до завершения звучания семпла. Важно – если будет задан параметр EndDelay – всё-равно сделает задержку после прошествии времени длины семпла
Очень важным компаньоном команды sample является команда specimen – она запускает семпл и не делает задержку для следующих команд, которые параллельно проигрываемому семплу могут выполнять ещё какие-то действия – например спецэффекты для семпла, или даже запускать другие семплы, которые начнут прерываться параллельно с текущим в рамках единого трека.
Введение в клавишную нотацию
Помимо прямой вставки семпла в партитуру трека, есть возможность зафиксировать его за всем треком
use instrument sample(“путь\имя семпла”) //Тут можно зафиксировать все необходимые параметры по умолчанию
Передача нот удобнее всего через паттерн клавиш
{keys: -A500+(D#200 E200 D#200 E200 D#200 E200) } //Нота «Ля», октавой ниже, звучит 500 мс, поэтому в начале получается аккорд (-А+D) нота Ре звучит 200 мс, после чего сменяется на «Ми», которая чередуется несколько раз с «До#» каждые 200 мс (но первые «До#», «Ми» и вторя «До#» буду сыграны вместе с «Ля», но за 100 мс, до конца звучания второй «До#», нота «Ля» перестанет звучать (истекут 500 мс)
Если не задать у ноты «Ля» время звучания, оно автоматически будет как у всего аккорда; при этом можно задать время в сего аккорда (даже такого сложного, с чередованием нот)
{keys: -A+(D# E D# E D# E):MainLen(1000) } //Тут вся последовательность звучит 1000 мс –время звучания каждой ноты будет одинаковым и вычислено из общего времени звучания (отдельным нотам можно задать их персональное время звучания – тогда оно будет вычтено из общего при расчёте звучания остальных нот)
Все ноты буду воспроизводиться текущим инструментом, заданным как семпл.
Число справа от ноты – это длительность звучания (без учета затухания). Символ «#» это диез (смещение на полтона вверх); есть и бимоль «&» - пример “D&200” – но применяется редко.
Если при воспроизведении ноты нужно указать какие-то особые параметры семпла – их можно указать в скобках вызова ноты
{keys: D#200(EndDelay=100) G(FullLen=200) D#200(EndDelay=100) G(FullLen=200)} //Число справа от имени ноты длительность звучания (без учета затухания) на это время будет пауза перед запуском следующей ноты; G(FullLen=200) задаёт длительность с учётом затухания; EndDelay=100 задаёт дополнительную паузу конце звучания ноты (от конца основного звучания) прежде чем управление перейдёт дальше
Можно и так записать
{keys: D#200:EndDelay:100 G:FullLen:200 D#200:EndDelay:100 G:FullLen:200}
Всё это в базовой октаве семпла. Октаву можно понижать и повышать – символы «-» и «+» строго перед именем ноты (ну или передать в ноту аргумент Octave=номер октавы – 0-я субконтр-октава –, 1-я контр-октава и т.д.) – сколько будет символов на столько октава будет сдвинута (а в примере выше -A25 – это «Ля» на одну октаву ниже базовой – т.е. «Ля» в малой октаве).
{keys: ---D200 --D200 -D200 D200 +D200 ++D200 +++D200} //Игра ноты «До» во всех основных октавах
Кстати, октаву можно зафиксировать для текущего контекста, например, для нотного паттерна – тогда относительные изменения октавы будут уже от неё, а «абсолютные» (числовые) останутся от базовой
{octave:3 keys: D200 +D200 ++D200 +++D200 ++++D200 +++++D200 +++++++D200}
Ещё одним способом явно указать октаву – её номер перед нотой
{keys: 3D200 2D200 1D200 0D200 1D200 2D200 3D200}
Замечу, что такой способ отличается от общепринятого, где октава пишется справа от ноты (так как, в данном случае, там располагается длительность), но такой вариант формата тоже возможен:
{classic: D1-200 D2-200 D3-200 D4-200 D5-200 D6-200 D7-200} //октава всегда должна быть указана
По умолчанию за нулевую берётся смещение на 4 октавы вниз до субконтр-октавы (но в настройках или в параметрах текущего контекста это можно изменить – но цифрами справа можно будет только прибавить октаву, но не убавить)
{octave:1 classic: D1-200 D2-200 D3-200 D4-200 D5-200 D6-200 D7-200} //задали нулевое смещение октавы
Замечу, что есть ещё один вариант записи нот (вообще их может быть много – если установить дополнительные интерпретаторы формата), из мира трекерной музыки – важное отличие: тут не задаётся напрямую длительность ноты – она звучит, пока явно не будет сброшена или не начнётся другая (ну если, нота зациклена – иначе звучит до своего конца и всё) – и тут каждая позиция имеет фиксированную длину тактов звучания (это всё настраивается), пропуск тактов «--» (обязательно отделено от нот) или «NP», заглушить ноту «00»
{ticklen:200ms tracker: D1 -- D2 -- -- D3 D4 D5 -- D6 00 NP NP D7}
Этот формат ещё много поддерживает фишек трекерной записи, но о них сейчас говорить не буду.
Нотные паттерны скрывают ещё много нюансов (например, можно задавать эффекты, силу/скорость нажатия и отпускания (или какие-то ещё техники, если речь не идёт про клавишный инструмент – это уже нюансы текущего инструмента), управлять громкостью и пространственным позиционированием и т.п.), но пока я вновь вернусь к описанию команд трека. Последнее, что добавлю – нотный паттерн так же поддерживает переменные (обычно речь о внешних, хотя внутри можно тоже объявить) и функции (в т.ч. генераторы) – ссылаться на них внутри паттерна можно обычным способом (по имени), но внутри паттерна есть свои ключевые слова – они переопределяют пользовательские идентификаторы (кстати, внутри паттерна можно переопределять существующие и вводить свои ключевые идентификаторы и переменные (в т.ч. внешние) через создание псевдонимов, сослаться на внешнюю переменную или функцию так же можно через префикс $ - за ним всегда подразумеваете внешний идентификатор (при необходимости получить адрес – последовательность спецсимволов такая «@$» далее идентификатор).
var len=800 {keys: D#(len+10) E(len+20) D#(len+40) E(len+80) D#(len+100) E(len+random(100)) }
аналогично (но переменная len существует только внутри паттерна; и фунукция даёт случайное число от 1, а не от 0)
def rnd() = random(1...100)
{ var len=800 keys: D#(len+10) E(len+20) D#(len+40) E(len+80) D#(len+100) E(len+rnd()) }
Введение в лупы
И так. Если нам нужно несколько раз подряд воспроизвести один и тот же семпл мы можем его написать несколько раз
sample(“путь\имя”) sample(“путь\имя”) sample(“путь\имя”)
А можно просто запустить цикл
repeat(3) sample(“путь\имя”) //можно ещё так sample(“путь\имя”):repeat(3)
Такими же способами можно зациклить и блок кода
repeat(3) { sample(“путь\имя1”) delay (200) sample(“путь\имя2”) Delay(200) }
или
{ sample(“путь\имя1”) delay (200) sample(“путь\имя2”) delay (200) }:repeat(3) //кстати repeat(0) не выполнит ни разу
Код, следующий за блоком цикла будет ждать пока не выполнится цикл, но если написать так
loop(3) sample(“путь\имя1”) sample(“путь\имя2”)
Выполнение семплов 1 и 2 начнётся одновременно, но на втором цикле будет запущен 1-ый семпл, независимо от звучания 2-го или какие команды там будут ещё вне цикла. То есть, loop цикл запускается параллельно текущему треку (можно считать, и по факту так оно и есть, что цикл запускается в отдельном субтреке, но с копией текущего контекста, и связанный с ним, и с его каналом; это похоже на оператор by, который тоже порождал параллельное выполнение – и внутри цикла он тоже может быть – и это будет ещё один поток параллельного выполнения).
Можно запустить и бесконечный цикл (если с repeat это не очень полезно, хотя – это как посмотреть), то с loop – будет куда полезнее (тем более что есть команда break – для прерывания цикла, а её параметр – это сколько вложенных циклов надо прервать (или можно указать конкретный цикл – об этом ниже)
loop { sample(“путь\имя1”) delay(300) sample(“путь\имя2”) } //Бесконечный цикл, пока существует трек, в котором он запущен
По сути loop – это отдельный поток исполнения (отдельный трек) и ему присуще всё, что касается управления параллельными потоками. Например, их можно прерывать извне
loop { sample(“путь\имя1”, FullLen=300) delay(300) sample(“путь\имя2», FullLen=300) ? checksignal(1) break }
repeat { delay(300) ? (random(4) == 0) -> signal(1); sample(“путь\имя3”, FullLen=300) }
//Здесь семрплы 1 и 2 могут звучать одновременно с семплом 3, или он звучит между ними, но случайным образом внешний код подаёт сигнал и цикл завершается (сигнал – не звуковой, а логический)
Но каждый цикл – это объект – поэтому можно и так
var myLoop = loop { sample(“путь\имя1”, FullLen=300) delay(300) sample(“путь\имя2”, FullLen=300) }
repeat { delay(300) ? (random(4) == 0) ->myLoop.Break(.End); sample(“путь\имя3», FullLen=300) }
Вместо Break можно вызывать Abort() – тогда цикл прервётся в любой момент времени (даже не доиграв семпл) или Stop() – тогда цикл остановится перед началом очередной итерации
Ещё вариант
var myLoop = loop { sample(“путь\имя1”, FullLen=300) delay(300) sample(“путь\имя2”, FullLen=300) break(.Check) }
repeat { delay(300) ? (random(4) == 0) ->myLoop.Break(.Manual); sample(“путь\имя3”, FullLen=300) }
Здесь «break(.Check)» сработает только если будет вызван «Break(.Manual)»
Наряду с break есть и команда continue – перезапускающая итерацию цикла (continue(.Restart) – перезапустит цикл полностью (если у него был лимит на число итераций или какая-то позиция), как будто цикл запустили снова.
Сигналы, удобны не столько для прерывания потоков (как выше можно заметить – они лишь маркер), но больше для синхронизации потоков
var myLoop1 = loop { sample(“путь\имя1”, FullLen=300) waitsignal(1) sample(“путь\имя2”, FullLen=300) waitsignal(2)}
var myLoop2 = loop { sample(“путь\имя3”, FullLen=300) waitsignal(1) sample(“путь\имя4”, FullLen=300) waitsignal(2)}
repeat(4) { delay(300) signal(1,10ms) sample(“путь\имя5”, FullLen=300) signal(2,10ms)} //10ms – вторым аргументом указывает длительность сигнала (после чего он автоматически сбросится, либо надо сбрасывать самостоятельно (signaloff(…)), либо сигнал без длительности автоматически сбрасывается при выходе исполнения из блока (блок в цикле считается всем циклом)
Есть схожая альтернатива сигналам – mark
loop { sample(“путь\имя1”, FullLen=300) mark(1,3) sample(“путь\имя2”, FullLen=300) mark(2,3)}
loop { sample(“путь\имя3”, FullLen=300) mark(1,3) sample(“путь\имя4”, FullLen=300) mark(2,3)}
sample(“путь\имя5”, FullLen=300) mark(1,3) sample(“путь\имя6”, FullLen=300) mark(2,3)
mark – это «сигнал» (не пересекается с обычным сигналом – это именно марк-сигнал) и ожидание в одном флаконе – тут два аргумента – первый идентификатор сигнала, второй счетчик – как только зарегистрируются все 3 марк-сигнала произойдёт продолжение выполнения и сигнал будет сброшен.
Но можно вызывать и так (причём тут опущен и идентификатор сигнала (будет общий) и счетчик (ведётся автоматически):
loop { mark(.Context) sample(“путь\имя1”, FullLen=300) mark sample(“путь\имя2”, FullLen=300) mark}
loop { mark(.Context) sample(“путь\имя3”, FullLen=300) mark sample(“путь\имя4”, FullLen=300) mark}
mark(.Context) sample(“путь\имя5”, FullLen=300) mark sample(“путь\имя6”, FullLen=300) mark
здесь mark(.Context) – автоматически определяет количество различных независимых контекстов, нуждающихся в синхронизации и настраивает макс значения текущего счётчика единым образом
Альтернативная запись через блок mark { }
loop { mark { sample(“путь\имя1”, FullLen=300) } mark { sample(“путь\имя2”, FullLen=300) }}
loop { mark { sample(“путь\имя3”, FullLen=300) } mark { sample(“путь\имя4”, FullLen=300) }}
mark { sample(“путь\имя5”, FullLen=300) } mark { sample(“путь\имя6”, FullLen=300) }
здесь будет синхронизация в конце блока всех начатых блоков (идентификатор блока задавайте по необходимости), после чего блоки можно заново начинать для другой синхронизации
Каждый цикл имеет возвращаемое значение и его можно присвоить переменной
var a = loop(3) { sample(“путь\имя1”) sample(“путь\имя2”) } //или var a = { sample(“путь\имя1”) sample(“путь\имя2”) }:loop(3)
В этой переменной содержится объект управления циклом. В примере выше применён цикл loop – по умолчанию он стартует сразу же в параллельном потоке, а код в текущем продолжает выполняться сразу за ним. Соответственно, через переменную цикла можно управлять этим циклом – в основном это команды потока: Pause, Resume, Break и т.п., но есть и более специфичные команды именно для цикла: Start, Restart, Continue. И некоторые команды управления контекстом выполнения.
Можно и такой цикл присвоить переменной
var a = repeat { sample(“путь\имя1”) sample(“путь\имя2”) }
Цикл repeat не выполняется параллельно, но в выражении присвоения он не стартует сразу (иначе бы присвоение не произошло, пока цикл не завершится и в таком присвоении не было бы смысла). Поэтому, чтобы цикл стартовать нужно написать так: a.Start(3) но можно и просто обратиться к переменной, как к функции a(3) – при этом цикл вполне можно вызвать несколько раз (в любом месте, где доступна переменная цикла):
a(3) a(4) a(3) //в аргументах вызова задаются значения выполнения цикла – в данном случае число повторов и это всё равносильно repeat(10) { sample(“путь\имя1”) sample(“путь\имя2”) }
Но это всё просто синтаксический сахар внутри переменной находится объект, описывающий цикл. И этот значение можно даже передавать в другие функции как аргумент.
Все циклы являются подпрограммами и автоматически захватывают переменные контекста (где цикл был определён). Но есть важное замечание – параллельный цикл loop обычные переменные захватывает по значению – в его потоке исполнения это будут копии переменных, хотя ссылки на объекты будут одинаковые) – изменение копии переменной не будет менять другую её копию (но изменения внутри объекта значения переменной будет единым). Такое поведение не является единственно возможным, тут много нюансов по синхронизации значений – про это будет отдельно в части параллельного программирования.
Честно говоря, как-то сильно заморочено. Напоминает другой проект, правда не про музыку а про трехмерное моделирование - OpenScad. Там тоже все операции делаются исключительно кодом. Но это же жутко неудобно, имхо.
А когда придумали Piano Roll представление нот, да хоть в том же Cakewalk - это сильно, прям в разы упростило написание музыки. У вас усложнение вижу я.
Честно говоря, как-то сильно заморочено. Напоминает другой проект, правда не про музыку а про трехмерное моделирование - OpenScad. Там тоже все операции делаются исключительно кодом. Но это же жутко неудобно, имхо.
Как написал Выше - у меня идея достаточно комплексная и многофункциональная! Но тут только практика может показать - удачная она или нет - лично я вижу за этим будущее - а пока я представил лишь отрывки из очень раннего черновика! и даже если мне не удастся придумать удобное решение, которое могло бы стать популярным хотя бы в кругах с определённым мышлением, то это не значит, что это невозможно в принципе!
А всё остальное - это просто ломка восприятия - сейчас музыканты привыкли к другому. А насчёт Piano Roll - знаете - есть серьёзные композиторы, которые до сих пор его не признают такой подход - просо их академически учили обратному!
У меня те же аргументы как и при противостоянии визуального программирования и текстового (см выше) - разве что визуальны партитуры музыки вряд ли когда-то будут иметь очень высокую визуальную сложность (хотя это Вы её Black midi не видели (с одноимённой группой не путайте - хотя их музыка и вышла из данного стиля) - вот микро кавер на известный мотив 26 сек и 230k нот, подлиннее и пожёстче - не для всех ушей 5.5 мин и 5М нот; ну или попроще, а это вообще шедевр или вот известная мелодия с постепенной раскруткой - такое только программировать... God mode reblacked
The Convergence - шикарно).
Создавать сложные мелодии, с кучей инструментов, с разнесением в 3D пространстве - это Вам не партитуру в несколько сот тысяч знаков накалякать - тут число генерируемых команд будет исчисляться ярдами на минуту контента! Да - это уже очень далёкая от классики музыка (но классику тоже можно - осовременить) - это музыка будущего (я не про Black midi если что) - сложная, объёмная, непостоянная (ведь тут ещё и случайные числа можно применять - так чтобы, условно, каждый семпл звучал несколько иначе - а не просто дублировался - что добавляет натуральности); Не говоря уже о том, что музыка может просто генерироваться на лету (причём вполне нормальная музыка - но тут, конечно надо глубоко настраивать, готовые части партитуры с вариациями исполнения и совмещения; эх... вспомнил как генерировала музыка в древней, не сыскавшей популярность, игре 7th legion - если начало шокирует - промотайте вперёд или смените трек)... А уж какие огромные возможности по программированию эффектов обработки звука...
Так же программирование музыки - это отличное подспорье для математических направлений в музыки - например для Math Rock, и везде, где нужна высокая точность гармонии
Безусловный ОФФтопик (хоть и контекстный) - но наглядный пример Black midi
Знаете, я когда-то экспериментировал с именно программированием музыки. Выглядело это так - два компьютера, на одном запущен Reason, и комп этот слушает midi порт. А что это такое? Да тот же уарт по сути. Поканально разведены ударные, бас, синтезаторы. А на другом компьютере программа на visual basic пихает байтики в выход миди своей звуковухи. Для начала я выводил из Cubase именно в миди порт, далее на втором компе звучали синтезаторы и все что надо. Затем я начал делать скрипты, меня интересовал DnB, PsyTrance, вот и я наделал шаблонов под ударные (они там не то чтобы сильно замороченные), переходы, мелодические и басовые линии отправлялись в порт (точнее процедуру, которая паковала их в ноты), сверху этого всего простейший табличный гармонизатор, и вот получилось просто охрененно. Совершенно убойный драмчик круглосуточно. Без нейросеток. Тупо по шаблонам, шаблоны это еще верх надстройки типа квадрат, переход, генерировать новую мелодию, от нее взять четыре ноты в бас, там транспонировать, повторять до начала нового квадрата или конца 4.
Шаблоны прямо в коде задавал, в тупом формате midi а именно ноту от 0 до 127, можно было написать нечто типа G7 но не заморочился. Накидал десять шаблонов и потом ходил кайфовал, музыка от компа, и драйвовая (очень зависит от шаблонов, те же ударные).
Где то валяется этот проект, но его придется переписывать с нуля. Слишком костыльно. А почему два компа? Ну потому что настроить Reason и чисто программный комп в 2010 было попроще, хотя и тогда был виртуал миди.
Очень здорово. Даже не ожидал узнать что-нибудь настолько интересное, когда писал свой комментарий. Спасибо, погружусь в изучение.
Табулатуры вижу регулярно в интернете, но их довольно трудно парсить, именно, с программистской точки зрения.
Сам в своё время освоил всё-таки ноты и успел купить Guitar Pro, чтобы их там вводить. Но я не настоящий музыкант, любитель, так что воспринимаю всё это как некую данность. Что-то придумывать в этой области не могу, не хватает знаний.
проектирую свой собственный ЯП для создания музыки под рабочим названием "Orange"
На самом деле в этой области ещё непаханное поле. Я тоже недавно накидал черновик спецификации для аналогичной задачи, тоже потому, что ни одно из существующих решений не зашло. Как минимум, чтобы иметь возможность русскими буквами писать "ля ля ля фа" в перемешку с гитарными и ударными табулатурами.
Очень любопытно! Я выше поделился отрывками из своих черновиков. Поделитесь тоже?
Не вопрос, но чуть попозже. Может вообще стоит в виде отдельной статьи оформить, раз нашёлся хотя бы один человек, которому это тоже интересно)
Вкратце: партитура разбивается на отдельные музыкальные фразы, оформленных в виде текстовых блоков с заголовком, например:
[гамма1]
до ре ми фа соль ля си +до
[гамма2]
до -си ля соль фа ми ре до
Я отказался от явного задания октавы в пользу контекста и служебных операторов. В данном примере "+" значит перескок на следующую октаву, а "-" соответственно вниз. Ноты октавы разбиваются в зависимости от тональности, до-мажор по умолчанию, другие задаются служебным оператором @key:Am
Длительность задаётся справа от ноты в виде модификатора с умножением и/или делением:
до/4 ре/4 ми*3/2
Ноты можно объединять в группы, чтобы задать модификатор один на всех:
(до ре ми)*2/3 // триолька
Также для группы можно задать количество повторений:
(до ре ми)x3 // то же, что и до ре ми до ре ми до ре ми
Можно задать громкость для каждой ноты:
до'100 ре'50 ми'10
Также к ноте можно привязять произвольное количество атрибутов, которые секвенсор или синтезатор при желании сможет обработать:
до<vibrato:3,detune:30,pan:-1>
Диезы, бемоли - по классике:
до# до&
Но можно их ставить перед нотой, а тогда его действие продлится до следующего такта (по стандарту нотной записи). В качестве конца такта выступает символ "|" (ну а какой же ещё). В этом случае потребуется бекар, для него я выбрал символ "%".
Помимо символьного обозначения нот можно использовать числа для хроматических отклонений от последней известной:
до 2 4 // то же, что и до ре ми
Ноты можно объединять в аккорды фигурными скобками:
{до ми соль +до} // прозвучат одновременно
По умолчанию, когда начинается следующая нота, предыдущая завершается. С помощью префикса "~" её можно оставить звучать до явного завершения префиксом "!". А "!!" завершает все звучащие ноты сразу:
~до ~ми !до ~соль !!
Вместо этого можно использовать несколько голосов, располагая их друг над другом:
:[1] . . си ~
:[2] . съ ~ ~
:[3] ми ~ ~ ~
Точка это пауза, одиночная тильда - продолжение звучания предыдущей ноты. Для ноты соль здесь использовано двух-буквенное сокращение, для всех нот также можно использовать стандартные латинские обозначения c d e f g а h.
Ну и таким образом можно нативно гитарные табы прописывать:
[:1 @root:64] 0 ~ ~ ~|5 ~ 7 ~ |
[:2 @root:59] 1 ~ ~ ~|5 ~ 6 ~ |
[:3 @root:55] 2 ~ ~ ~|5 ~ . . |
[:4 @root:40] . . . .|. . . . |
[:5 @root:35] 0 ~ ~ ~|0 ~ ~ ~ |
[:6 @root:30] . . . .|. . . . |
Как-то так.
Да, но вы знаете про трекерную музыку? Это совсем не MIDI, и хоть это не ЯП, но нечто похожее в самой идее.
Да, я понял. Вы увидели, как звукореж юзает планшет и поэтому
Тенденции с компьютерами заключатся в том, что системные блоки стремительно сжимаются
но это ж не значит, что их вообще покупают за пределами офисов.
Зря, кстати. Как раз те, что на авито (они и сейчас продаются) - и имеет смысл брать. В качестве второго компьютера-'пишущей машинки' и хождения по интернету совершенно замечательно подходит.
Вообще сейчас есть уже достаточно мощные мини ПК, да, они немного задушены, но они действительно выдают хорошую производительность,
например Kingnovy S600 Intel i9 13900H
При желании к ним можно отдельно подключить внешний GPU. И вот GPU как раз очень даже растут в размерах, правда это растет их охлаждение. Если видеокарту и такой миниПК посадить на воду типа mora3, то будет две очень маленьких коробочки и один бесшумный радиатор охлаждения.
но это ж ноутбучное железо со всеми вытекающими..
i9... ага, в ноутбучном исполнении
Ага, и мору размером с радиатор от белаза :)
хорошую производительность выдает десктопное железо. оно как бы под это и заточено
а ноутбучное железо заточено под низкий теплопакет. Ну не возможно отвести 300 ватт тепла (а это просто i7, а не i9) десктопного процессора. засунув его в ноутбук
Поэтому декстопы лучше
просто первый же тест
https://technical.city/ru/cpu/Core-i5-13600K-protiv-Core-i9-13900H
ну ок, но юзать ноутбуки (и железо от ноутбуков) и 10 лет назад никто не запрещал. И 20 лет назад тоже никто не запрещал
Тренд то в чем?
Было бы желание. Вот например 4090FE в корпусе 5л.
Но это, конечно, для гиков. Обыватель наоборот будет использовать калорифер литров на сорок.
ну это ж для фана. в массе своей в офисы и людям продают унылые черные коробки (кто-то домой покупает аквариумы. Во-первых это красиво светится)
у меня самого было nr200, но это совсем не типовая история
даже больше скажу, "сбор своего компа" это отдельное хобби (которое на пост-СССР живет из-за малых доходов + инженерная культура), для тех же американцев, можно просто купить готовый комп и не заморачиваться
собственно и у нас можно, но считается "фу, как ты мог" :)
мы то про тренды тут спорим, а то, что есть энтузиасты, так конечно есть, но они на масс-маркет не так чтобы влияют
вот кмк, начало популяризироваться SFF, китайцы наплодили неплохих корпусов. Но! внезапно, ITX материнки не дешевые (ну по крайне мере от а-брендов) и самое популярный формат mATX
Но повторю, сам формат ITX существует довольно давно (ну наверно как сам стандарт АТХ). и скорее можно сказать, что е-атх по сути мертво, а вот и корпуса и материнки АТХ вполне себе существуют. И пока этот формат есть, говорить о трендах по стремительному уменьшению корпусов мягко скажем опрометчиво
А те, маленькие коробки, с задушенными i3, конечно продаются, но что они реально меняют в плане трендов
для тех же американцев, можно просто купить готовый комп и не заморачиваться
Нет, вопрос на 95% к позиции и мышлению (хобби). "Не заморачиваться" -- это для этих людей означает купить приставку (консоль).
А коим образом ПК сфера начала переживать ренессанс у западной публики (здесь, именно что, американской) - я так и не понял, но факт налицо. Опирающиеся на щедрые маркетинговые бюджеты (от билетов на перелеты до просто кучи (временно)бесплатных железок под тесты) и платеже- и донатоспособную публику, каналы типа LinusTechTips, GamersNexus, Hardware Unboxed ушатали вообще всех. Выросли настолько, что не боятся идти против маркетинговых команд, за что получали "баны" на железки для обзора.
каналы типа LinusTechTips, GamersNexus, Hardware Unboxed
И примкнувшие к ним.. (и там же есть Дмитрий)
Кстати, может мне показалось, но они в большинстве канадцы
LTT и Hardware Canucks - Канада; далее США и Австралия. Кроме Jayz 2 cents (побольше команда) остальные одиночки из США. Какого-то вменяемого присутствия остальных стран в этой тусовке я не вижу, кроме der8auer, который полноценно на обоих языках ведет канал(ы). Дальше идут текстовые публикации и при них каналы поменьше.
А почему с "задушенными i3"? Делловский OptiPlex 7070 вполне себе i7-9700 с 16 гигами в формате 95х290х290 мм... С моей точки зрения тоже странно выглядит утверждение о трендах на изменение размеров корпуса - но и говорить о "задушенности" не стОит, ИМХО. Рассуждение о "листе ватмана", как о полностью функциональном компе выглядит несколько архаичным - будущее, скорее всего, за распределенными системами и упомянутый "лист ватмана" будет, очевидно, просто разновидностью удаленного интерфейса к арендуемому виртуальному компу в универсальном вычислительном пространстве (могу же я пофантазировать тоже 🙂?)
Простите, куда системные блоки сжимаются (причем аж даже стремительно)?
Они всё-таки становятся меньше, причём может даже несколько в ущерб функциональности (видел корпуса, где крепление под жёсткий диск просто не предусмотрено, предполагается, что будет SSD 2.5"). Ну и в целом современные системные блоки легче, разница хорошо заметна, если есть склад, на котором лежат старые системники, которые надо бы списать.
какой ссд, все уже на m2 переходят. Но жесткие диски да, в бытовом смысле не нужны
но за счет того, что спереди не надо делать полку под ХДД, впереди ставят вентиляторы (то на то и выходит в классическом корпусе. Экономия по литражу есть у спец-корпусов - однообъемников, у меня есть от джонсбо d40 (или 41, не помню уже)
легче они потому что железо экономят. а не потому что "системные блоки сжимаются" :)
в общем и в целом, пока жив стандарт АТХ, никаких кардинальных изменений не будет. Потому что все делают под этот стандарт, все учитывают возможности систем охлаждения.
например, товарищ Хуанг с племяшкой наверняка могли бы выпустить более мощную видеокарту с ТДП ват этак в 1000. Но не выпускают, потому что ее будет сложно как разместить в корпусе, так и запитать и охладить (хотя инженерно задачча решаемая)
а те спец-версии процессоров с индексом t, ну не сказать чтобы какой-то тренд. и кажется и 10 лет назад выпускали. Ну или просто продавали целероны-атомы
сжимаются и с 4090 очень хорошо, но для программиста (не игр и не ии) видяха в целом мощная и не нужна, достаточно встройки
а про ноуты - стандарт индустрии это макбуки, вот и здрасте "обрезано"
сейчас эппл вот iPad выпустила на самом мощном их чипе
а вы продолжате мыслить как "ноут это не системник" - это такой же пк, просто удобнее.
понятно что если мыслить как вы, то и суперкомпьютеры до сих пор занимают целые здания, ну да, только в ту же площадь умещается большая производительность, но такая огромная производительность не всем нужна. Точнее большинству не нужна.
сжимаются и с 4090 очень хорошо
Ну что значит "очень хорошо", когда Вы показываете крайне атипичный корпус? Поделитесь плиз сетапом, Вы ж наверняка знаете, а не просто дернули картинку с интернета
но для программиста (не игр и не ии) видяха в целом мощная и не нужна, достаточно встройки
А причем тут программисты, когда обсуждали тренды на рынке десктопов
а про ноуты - стандарт индустрии это макбуки
какой индустрии?
> "ноут это не системник" - это такой же пк, просто удобнее
Ноут и правда не системный блок. Да и удобство это относительное. Ноут - это набор компромиссов
в ту же площадь умещается большая производительность
ну да, производительность и правда растет, но тезис, с которым я спорил звучит так
системные блоки стремительно сжимаются
Не "производительность растет на один кубический сантиметр", а именно объем системных блоков сжимается
Ни жестами, ни голосам программировать не будут. IBM проводили исследования, за день человек тупо устает разговаривать. А еще поищите скорость передачи и восприятия информации через разные каналы, текст это самый быстрый способ на данный момент. Дальше только чипы в мозг.
Ну, нет, так нет. Будут люди носить с собой лист ватмана, а также мышь и клавиатуру. Или возможны варианты. Я вот не думаю, что там надо будет прямо "разговаривать", скорее, время от времени произносить названия.
Зачем что-то куда-то носить? =/
Ну, я не знаю. Уже лет двадцать, как ноуты повсеместно используются. Не слышали?
Ну вы нам про чудесное будущее рассказать пытаетесь. А там всё так же как и 20 лет назад.
Эээ нет, не слышал.
Зачем разработчику ноутбук ? В офисе и дома у меня нормальные компьютеры. К слову сказать сосед проапгрейдился и его башня шире стандартной процентов на 30. Иначе не влезает водяное охлаждение ;(. Гроб громадный.
В командировке ? Все последние разы мне выдавали тачку на месте сразу же, и я мог запускать на ней свои контейнеры привезенные на флешке.
В метро я не программирую. Зачем ноутбук непонятно.
Кстати еще лет 10-15 назад ноутбук в командировки приходилось возить. Чтобы не копаться с настроенным окружением итп. Сейчас работая в виртуалках это слава богу не нужно.
Вы очень странные вещи пишите, серьёзно. Мне выдают ноут на работе последние лет десять, наверное. Но дело даже не в этом.
Вы тратите свои аргументы впустую. Цель моего комментария была — пофантазировать на тему, затронутую в статье, потому что она мне близка, возможно, вызвать кого-то на обсуждение и моделирование, какими могли бы быть удачные визуальные языки программирования.
Вы докопались к отдельной детали, и мы просто зря тратим время на её обсуждение. Ну, живёте вы в вашем мире с тауэрами, и живите. Это просто значит, что обсуждение перспективных идей не для вас.
В метро я не программирую. Зачем ноутбук непонятно.
Удобно на пузе держать, вот сейчас так пишу )))
У меня уже 7-й нотбук за 20+ лет программирования. Стационарных вообще не покупал для работы. Удобно во всех смыслах и за это время стало только еще лучше.
Вы лежа работаете что-ли? Я сидя, у меня какой-то монитор размером с современный телевизор, удобная клавиатура и мышь. Мой системник имеет детали купить которые я могу в течении пары часов, и вообще он неплохо охлаждается кучей вентиляторов, стоит в отдельном помещении и я его не выключаю неделями.
Зачем мне ноутбук? Чем он лучше то ? Он менее надёжен, медленнее (особенно за те же деньги), у него неудобная клавиатура, мышь, маленький экран. Чего себя мучать-то ?
Я понимаю, когда зачем-то нужна мобильность. Там да, приходится терпеть. Но разработчику то зачем ?
Секрет открою, зачем разработчику ноут.
1) производительность отличная
2) на рабочем месте к нему подключена удобная клава и мышка и монитор (или 2)
3) ну а если нужно всё таки выйти, то всё моё, со мной.
Нет, в электричках и метро не работаю, у берега моря на шезлонге тоже. Но!
Но, если нужно уехать к родителям, то могу поработать, с меньшей производительностью, но могу. И производительность снижается именно от клавы и мышки и ещё от кресла и вот этого всей посадки. Но точно не от того, что чего то, не установлено, настройки не те.
При наличии денег на нормальный ноут, понять зачем мне работать за десктопом - не могу.
Десктоп с видяхой, тока в игрушки гонять.
Вы правильно указываете на существующие желания пользователей:
пользователь хочет большой экран
пользователь хочет иметь доступ к экрану в любом месте
Но вы неверно решаете проблему: пусть таскает "сворчивающийся ватман".
А все потому что ваши требования противоречивы. Правильный ответ уже существует, но нужно еще несколько итераций чтобы сделать его удобным.
Шлем AR/VR (Apple Vision Pro) -> Легкие очки (Magic Leap) -> Контактные Линзы (тот же Google пытался) -> чип в мозг "рисующий" картинку напрямую (+20 лет минимум)
Решение не в том чтобы таскать физический объект, а в том чтобы проецировать изображение в поле зрения человека. Текущие решения упираются в точное управление на таком "экране", но для большинства сценариев точность не нужны, а для остальных случаев будут появляться специализированные контроллеры (до момента когда это все не залезет в мозг).
С Вами соглашусь в том, что будущее за декларативными языками программирования! Но... вот визуализациям им, средство ввода исходника, нафиг не нужна будет - хотя... как некоторое подспорье в ряде случаев - будет полезно - но только как вспомогательный инструмент - условно когда надо глянуть на итоговую схему, прогнать тесты и отладку, быстро переключить какие-то оптации!
Но, всё же - основной код буду набирать и редактировать в текстовом представлении! Причём декларативность тут позволяет писать его очень абстрактно, разбрасывать по куче мест - и потом всё это будет собираться вместе - а итоговый код строиться на основе статической интерпретации всего этого декларативного и макро описания!
Возможно, от клавиатуры и мыши никуда не деться. Но вообще интересно пофантазировать, если языки будут визуальными, то какими?
Какие варианты?
Лично я считаю что тут не может быть какого-то приоритетного визуального представления - всё это очень специфично и индивидуально - то есть визуальный ЯП просто должен иметь несколько визуальных представлений (выбор между которыми будет зависеть от самого кода/задачи, от предпочтений разработчика, инструментальной базы IDE). И само собой, обязательно, должен иметь и текстовое представление! И да - так же будет прямая зависимость и от текстового синтаксиса и общей семантики такого ЯП. Здесь нет какого-то одного верного решения!
Но подчеркну - вряд такая визуализация как средство ввода алгоритма станет маломальский популярна - от того и развиваться она будет очень медленно!
Мне тоже кажется, что не будет одного варианта, а будет несколько.
Есть, правда, идея, что все программы могут быть представлены, как в LISP. Каждое S-выражение из LISP можно нарисовать в виде дерева. Наверное, эти рисунки будут визуально громоздки, так как сложные математические формулы будут представлены как большие куски деревьев, похожих на абстрактные синтаксические деревья.
Но, возможно, это будет только начало.
Компьютер превращается в инструмент решения задач. Иметь компьютер ради компьютера - вариант все менее и менее популярный. В основном в учебных целях. Раньше для прослушивания музыки и просмотра фильмов был период, когда компьютер очень сильно выручал. Сейчас муззыку слушаем без экрана (умные колонки), видеоконтентом пользуемся довольствуясь классическим набором телеэкран+пульт.
К чему я? Для решения задач интерфейсы взаимодействия уйдут в узкую специализацию. Возможно и программирование ждет то же самое.
Интересное наблюдение. Звучит логично
Сдаётся мне, что прорывом к "визуальному программированию" послужит технологический переход, а точнее уход )
Обратите внимание, как обсуждение скатывается к мышкам, мониторам, клавиатурам... А они все именно про текст. Мышка не совсем, но всё же ещё там.
Действительно: очки, планшеты со стилусами + голос + жесты и возможно даже мимика..
Но пока это именно только наброски, вот когда это появится, все дружно скажут, да блин, вот же.
Короче, до тех пор пока мы говорим программирование и понимаем за этим написание кода - визуального не выйдет. Кому-то предстоит вырваться из этого круга. И вряд-ли это будет "визуальное" программирование - скорее всего и термин будет другой )
Тенденции с компьютерами заключатся в том, что системные блоки стремительно сжимаются, в то время, как мониторы не менее стремительно растут в ширину и высоту, становясь при этом всё тоньше.
“Мое хобби экстраполяция”. А экраны телефонов все растут в размерах и становятся гибкими, поэтому скоро мы будем заворачиваться в лист телефона, чтобы поговорить.
Визуальное программирование как полностью самостоятельное направление вряд ли когда-нибудь взлетит. На то есть несколько причин:
Так уже исторически сложилось, что людям проще работать с текстами и под это активно затачивались все текстовые процессоры и IDE - читать и вводить буквы просто проще, как и выполнять разные операции над текстами. Да - визуализация как бы считается более лёгкой для восприятии - но об этом ниже. Да - можно попробовать создать удобную и очень продвинутую IDE и натаскать на неё человека - но уверен сложность такой среды будет куда выше чем у текстового процессора! Хотя, может и удастся с ней работать хорошо натасканному специалисту достаточно просто!
Компьютерным алгоритмам так же куда проще работать именно с текстовым преставлением - и тут вообще ничего не изменится. Кроме того - роль автоматизированной обработки текстов с каждым десятилетием будет расти и расти!
С текущими средствами ввода и манипулирования данными - человеку куда проще вводить данные (алгоритмы) с клавиатуры, чем, скажем, мышью. Вот когда разработают что-то более продвинутое для ввода - может что-то и изменится. Но даже силой мысли или в VR оперировать текстами, мне кажется, по-прежнему будет проще...
Действительно, визуализация очень хорошо может восприниматься человеком... но.... только до определённого уровня сложности - затем происходит перелом и обратный процесс - восприятие резко падает. И все попытки разбивать визуализацию на кластеры детализации только усложняют детальный анализ. Да - сложные тексты тоже бывает очень непросто анализировать и воспринимать. Но тут есть методики по их написанию и средства упрощения их преставления и анализа, и ориентирования по таким текстам - и они хорошо работают!
Визуализация алгоритмов только может стать хорошим подспорьем в стандартных текстовых IDE как отдельный инструмент - либо для простых алгоритмов и новичков, либо как дополнительное средство анализа кода - например при поиске ошибок - т.к. позволяет эффективно визуализировать движение по коду в динамике, в т.ч. в виде активной схемы в реальном времени выполнения!
Так же визуализация может быть удобна для ряд узких задач программирования или для представления данных: это нейросети и какой-либо кластерный анализ
Забыл добавить ещё три очень важных пункта:
Этот пункт - дополнение к 1. Более менее простую визуальную схему нарисовать достаточно легко. Но - как только начнёт расти количество элементов - первое с чем все сталкиваются - это как размещать это всё на плоскости и как размещать связи между бллками. Это реально очень большая проблема - когда рисуются комплексные схемы - банально - как это всё структурировать на 2D, квази 3D, настоящем 3D. Спросите любого схемотехника - для него это головная боль. Да, для рисования, условно, электрических схем есть продвинутые IDE - помогающие с эффективным расположением элементов - но не решающие эту проблему. А схемы чертят уже очень давно...
Но даже если Вы всё эффективно разместите - и тут нате... нужен рефакторинг, ну или просто изменения в логике алгоритма - и даже пусть продвинутая IDE вам позволит технически (это уже другая проблема - см. п.1) быстро изменить логику - но свою красивую визуализацию Вы тут же поломаете - и всё придётся ровнять заново!
С текстами всё проще - есть несколько прямых рекомендаций и правил а-ля "чистый код" - но даже если их соблюдать - условно тексты просто структурируются сверху вниз - иногда немного вправо - и всё. Да тут тоже есть свои нюансы и недостатки восприятия 0 но современные IDE активно пытаются их решать! И здесь есть ещё что совершенствовать и куда развиваться!Повторное использование кода, сборка комплексных элементов из отдельных модулей, файлов, да и просто разных частей - расположенных в разных местах - это всё реалии современности - код перестал быть строго линейным - он может быть разбросан по проекту, по библиотекам проекта - и собираться по кусакам (пример - да хоть частичные классы, или методы, вынесенные за пределы определения структуры класса), а изначальна описываться очень абстрактно. Текстовое представление отлично к этому приспособлено. А вот у графического тут явно будут большие проблемы именно на стадии исходника - конечно представить уже собранное решение графически будет уж "не так сложно" (но см. пункт 8.),
Так же и обратное - декомпозировать сложный текст - не так уж сложно - декомпозировать сложное визуальное представление - это кошмар...Сейчас разработкой рулит Git ну или в общем случае - версионирование кода - со всеми инструментами сравнения, объединения, пул-реквестов и веток. И для текстового представления всё это подходит отлично! А вот с графическим представлением будет большая жоп.... Особенно кода решение в итоге собирается из нескольких источников и так же из нескольких источников обновляется... Я не говорю о том, что для графической визуализации проводить сравнение и мердж невозможно - тут могут быть и свою интересные фишки - но проблем, всё-равно, будет куда больше, чем с текстами...
Поэтому сейчас наоборот - в разработке есть обратная тенденция - там где раньше рисовали схемы визуальными средствами - сейчас переходят на текстовый кодинг. Начиная от UML XML и до DocHub. Да хоть посмотрите и формат векторных изображений SCV.
И я сейчас, порисовав некоторое время кучу схем визуальными средствами - уже видеть все этм редакторы не могу - это просто убожество - и хочу далее рисовать схемы только текстом! То же и про векторную графику - дайте мне лучше редактор с командами для рисования графических элементов!
То же и про UI формы: XAML, Jet compose, Swift UI, Flatter - Это всё прекрасно (хотя синтаксис я бы ещё существенно доработал бы - и с текстами провести такие доработки, в т.ч. переписав компиляторы, будет провернуть куда проще, чем с графическими системами)!
Отдельно замечу про... устный ввод! Вроде бы есть тенденция к возможности реализации ввода программного устным набором - начитка! Лично я не сторонник такого подхода (хотя устный ввод может быть хорошим подспорьем для рефакторинга и управления прочим инструментарием IDE). Но я считаю так - что при устном вводе (и тем более при вводе силой мысли) грань между способом текстового кодирования и визуального рисования уже сильно стирается (с учётом конечно несколько разных техник команд общения и очень продвинутой IDE, которая эффективно будет решать проблемы восприятия и авто визуализации). При этом со стороны наблюдать за графическим представление отчасти может быть даже удобнее чем за текстовым! Но... до этого ещё очень далеко - и, лично мой мнение, что бы так не вводилось - текст или визуальные схемы - это всё-равно будет менее эффективно - чем прямою ввод руками с клавиатуры (или как-то ещё иначе - но с точным преобразование механики нервных импульсов к текстовый поток); и тем более - если такой символьный поток ещё и параллельно дополнить вербальными командами лица, для управление IDE и интеллектуальным помощником ввода!
Это все так, но есть вариант транслировать прямо в мозг
В каком виде?
Это только на словах звучит эпично
Если б я знал будущее... Во-первых разработки взаимодействия напрямую с мозгом уже ведутся, а во-вторых прогнозировать как оно в будущем - такое себе занятие, обычно мало у кого получается зайти дальше "ну, эта штука будет в Х раз быстрее, и У раз меньше"
Вопрос то был не про техническую часть - а как раз пофантазировать о том, как это визуально т.е. с практической стороны восприятия могло бы быть - ну и сделать оценки эффективности такого решения!
А насчёт технической части - да в мозг лезу уже сейчас - и, возможно, когда-то научатся очень умело им манипулировать (так что будущее "Матрица" покажется Вам раем, а вот будущее "Континуум", или" 2035: Город-призрак" - очень пугает, так что может не надо?) - но, думаю, это ещё очень и очень не скоро... ту скорее программы сами себя быстрее начнут писать - и человек тогда вообще не понадобится!
Основная проблема - сложность. С проектом в миллион строк кода я обращаюсь достаточно легко, но проектом даже в тысячи визуальных инстансов мне кажется будет не подъемным для понимания
Согласен в целом со статьей.
В моей области (геймдев) есть много попыток использовать визуальное программирование, самое известное наверное Unreal Blueprints - визуальный язык для Unreal engine.
Но все это считается несерьезным по целому ряду причин.
Я думаю самая важная - быстро растущая комплексность делает эти диаграммы совершенно нечитаемыми паутинами, а средств организации кода, подобных модулям не придумали. Точнее что-то придумали, но использовать сложно, что противоречит идее "легкого входа". В итоге классический код становится хорошим компромиссным решением между сложностью написания, чтения и распознавания взаимосвязей.
Но есть много специализированных областей, в которых это может быть оправданно:
- Редакторы шейдеров. Их можно писать кодом, но в визуальном программировании можно получить визуализацию промежуточных результатов, что обеспечивает глубокое понимание и легкую отладку того, что ты делаешь
- Редакторы анимаций (по сути машины состояний) - аналогично, даже большие деревья все еще доступны для понимания, все узлы более менее однообразны.
- Часто делают редакторы квестов/диалогов в виде деревьев. Тут нужно упомянуть, что хотя это и распространенное решение, так же часто используются и DSL, где это описывается обычным текстом. Например многие чатботы содержат деревья с визуальным программированием для начинающих, но более продвинутые версии все равно описываются через DSL
- Я делал даже небольшой ЯП для геймдизайнеров на объектах, хотя по структуре он был ближе к scratch - скорее там были последовательности команд списками, нежели деревья или визуальное программирование. На самом деле основной плюс такого языка был в том, что не нужно было знать синтаксис, только основные принципы. Команды и переменные выбирались из списка.
В общем потенциал велик, но на пути использования визуального программирования есть серьезные проблемы, которое даже классическое программирование не научилось решать.
И рано или поздно это упирается в самую главную проблему обычного программирования - войну со сложностью.
И если для больших систем это научились худо-бедно решать, то с визуальным программированием беда.
Я надеюсь, что визуальное программирование останется как явление и будет развиваться, так как на личном опыте использования тех же Блупринтов и FlowGraph из CryEngine (даже не знаю, остались ли они там, давно не пользовался) заметил, как подобные инструменты упрощают работу не специалистам, вроде меня. Т.е. на лицо большая специализация/упрощение, ценой сокращения возможностей.
Классическое же программирование, на мой взгляд, требует более основательного подхода, хотя и даёт больше возможностей. Нельзя просто вытянуть ноду PrintString и вписать туда нужный текст, для начала нужно решить, через что этот текст будет выводиться и есть ли у программы вообще окно вывода.
В моей области (геймдев) есть много попыток использовать визуальное программирование, самое известное наверное Unreal Blueprints - визуальный язык для Unreal engine.Но все это считается несерьезным по целому ряду причин.
Лучше бы Epic-и дали нормальный скриптовый язык со знакомым синтаксисом, не требующий перекомпиляции после каждого изменения. А то либо Blueprints, которые сложно использовать с git, которые ломаются в неожиданных местах при рефакторинге и легко превращаются в спагетти, либо C++, который иногда(!) умудряется собраться через live coding (иногда при этом ломая связанные blueprints), но чаще требует закрывать unreal и перекомпилить (генерируя pch и прочих Intermediate на десятки GB и тормозя рандомное время, от 3 сек до получаса), не отлаживается в окне unreal, крашит редактор в случае банальной ошибки в коде.
Программирование не в одиночку - это VC, сравнение и слияние изменений от разных людей, разрешение конфликтов, ревью кода. И если формат текстовый - то есть мешок инструментов, что все это умеют делать. А вот для визуального отображения придется все это писать практически заново. Желающих мало.
В статье всё намешано. Заголовок про визуальное программирование, но говорим о визуализации кода и данных. Это так то разные вещи.
Мне кажется визуальное программирование потихоньку взлетает - то тут, то там графовые редакторы вполне неплохо справляются. Главная проблема, имхо, что часто в таких графах пытаются решить низкоуровневые задачи. Отсюда макароны и малая скорость.
Визуальное программирование должно быть только для высокоуровневых задач. Подкреплено снизу хорошей кодовой базой. И тогда это будет такой же шаг в разработке, как когда-то был от ассемблера к С
«Балет на льду и хоккей на траве» ®©™.
С маниакальным упорством люди пытаются описать логические элементы текстом (VHDL), а алгоритм — диаграммами.
Начните с визуального «программирования» ПЛИС, может, дальше-то и идти не придётся?
Начните с визуального «программирования» ПЛИС, может, дальше-то и идти не придётся?
Здрасте. Мучались-мучались с визуальным программированием и когда сделали текстовый язык, вся индустрия на него с радостью переползла, потому что в масштабах современных процессоров визуально это делать нереально.
А есть класс алгоритмов, которые замечательно описываются диаграммами — событийная логика, когда сообщение летит и попадает в ноды, которые с ним что-нибудь делает и отправляют сообщение дальше.
Написание кода уже "визуальное", просто образы в голове, а не на бумаге. Что-то трудно представимое, обычно, дополняется комментарием, названием алгоритма, ссылкой и т.п., где картина достраивается. А тут, получается и то, что обычно напечатано, и то, что обычно в голове, переносится на лист, отчего общая картина очень быстро вырастает в размерах. Для какой-то простой кастомизации поведения сойдет.
Рассуждения про бесполезное визуальное программирование без единого слова о Labview, у которого нехилая такая доля рынка промышленной автоматизации - ну такое.
Сегодня LabVIEW стал де-факто стандартом разработки инженерных систем и прочно занял свою нишу. С развитием робототехники, скоро LabVIEW он выйдет за рамки простой среды для инженеров и станет доступной всем желающим сделать свою систему. Чем собственно и занимаюсь.
С развитием робототехники, скоро LabVIEW он выйдет за рамки простой среды для инженеров и станет доступной всем желающим сделать свою систему.
И каждая домохозяйка сможет спроектировать робота?!
Мне кажется до домохозяек тоже это дойдёт - и тому будут две причины:
Продвинутые специализированные фреймворки "для чайников" + AI ассистенты + графическая визуализация (да хоть структурированная, да хоть по частям) дадут колоссальную поддержку в формировании программного кода
Людям придётся осваивать и программирование роботов так же как и когда-то пришлось осваивать бытовую технику, смартфоны и домашние компьютеры + я считаю, что повысится и уровень образовательной программы, подстраивающийся под реалии прогресса и быт, требующий более сложных знаний + будет совершенствоваться и автоматизироваться, и, в то же время, образовательная программа и средства обучения - дети уже с детского сада будут окружены цифровыми технологиями и индивидуальным подходом - думаю, что, и итоге, сам термин "домохозяйка" в текущем, чаще негативном интеллектуальном окрасе, уйдёт в прошлое - общий уровень повысится....
но.... безусловно, возможен и обратный процесс (и он весьма вероятен) - когда всеобщая автоматизация наоборот будет отталкивать людей от самосовершенствования и развития - всё больше направляю их по деградационной шкале к уровню животных - которым и корм дадут, и лоток уберут, и на прогулку выведут, и развлекут...
Но я не верю в долгое нахождение в промежуточном состоянии развития - оно не устойчиво - ведомое AI и тотальной автоматизацией человечество пойдёт в своём развитии либо в верх либо вниз (но возможны и периодические колебания - с длительными циклами нахождения в том или ином состоянии - тут многое зависит от того - как с таким человечеством справится этот самый AI - сумеет о его сохранить и направить на путь развития - или сочтёт это дело бессмысленным)!
Но всё это, на мой взгляд, ещё очень не скоро ждёт человечество - и деградация, и домашнее повсеместное программирование роботов, да и сами повсеместно распространённые роботы и продвинутый ИИ - я думаю от этого нас ещё отделяют столетия развития технологий....если за это время человечество не умудрится и без ИИ отправить себя в каменный век!
Но... тем не менее.... домашние программируемые роботы появятся, скорее всего уже во второй половине XXI века, пусть и с примитивным AI
Но программировать роботов на бытовом уровне, всё-таки, будет проще голосом - но на телевизоре/планшете может выводиться какая-то вспомогательная графическая информация
Людям придётся осваивать и программирование роботов
Только это будет не программирование (во всяком случае для большинства), а как с домашними животными. Пинаешь палкой-погонялом роботов - уборщиков, когда они косячить начинают - ну вот и хорошо.
Кто его знает - сейчас трудно дать чёткую оценку тому, как будут программировать роботов лет через 100-200
Но Вы учтите - что лет за 100 и текущее - текстовое программирование в своей массе тоже сильно видоизменится! Как это уже происходило - пару раз - сначала переходом от перфокарт/перфолент как раз так и к примитивному текстовому вводу инструкций (от ассемблера до С++ и далее)- а затем второй раз - к более абстрактному программированию намерений (от Lisp/Prolog до SQL/NoSQL и далее). А современные ЯП - это скорее уж химеры, сочетающие стороны обоих подходов! Но я верю в то, что большая часть прикладного программирования будет всё больше уходить в обобщённое абстрактное программирование - в декларативной форме... такое, что гуру ЭВМ прошлого века точно бы не назвали классическим программированием - а уж противников, считающих, такой подход извращённым есть сейчас и будет через сотни лет - ещё вполне много - системное программирование навряд ли далеко уйдёт за ближайшие лет сто от прямых инструкций... Но роботов явно не будут программировать ни дома ни на "заводе" прямыми инструкциями - так что ЯП для них, что примышлённый, что домашний - вряд ли будут сильно отличаться по своим возможностям (но доступ к библиотекам и доступ к данным настроек - конечно будет различный, как и сложность этих библиотек и настроек - как это есть и сейчас - не всем дано ковыряться в недрах ядра ОС или БИОС, или даже системном меню бытовой техники)!
В основе любого логического ядра, какими бы совершенными не выглядели инструкции IDE визуального визуального программирования, всегда будет низкоуровневый язык, т.к. концептуально процессорная (микропроцессорная) техника, аппаратно предопределена на работу с бинарным кодом. Хорошо это или плохо, нас последователей однажды построенной аппаратной концепции в те далекие года никто не спрашивал. Впрочем думаю все же последнее слово будет за нейробиологией и органикой с принципиально другими понятиями логического контроля и управления.
Я же выше написал - что системное программирование ещё долго будет с нами - и там будет править классика. Но, объёмы такого программирования будут год от года снижаться. А вот объёмы кодогенерации, в т.ч. и в области системного программирования будут год от года расти. А визуальное и декларативное программирование будут как раз стоять на фундаменте низкоуровневой кодогенерации и некоторых системных готовых библиотеках!
Каждая скрипт кодерша уже сейчас должна заботится о своих скилах в области визуального программирования, т.к. естественная языковая эволюция никого не пощадит и превратит ее в домохозяйку, как это случилось с фортранщицами, паскальщицами и прочими ассемблями.)
Читаю про Labview и понимаю, что мечтал о таком инструменте всё это время. Спасибо, что упомянули!
Хоть я и сижу в геймдеве, всегда тянулся к визуальным языкам (FlowGraph в CryEngine, BluePrint в UnrealEngine), а здесь вижу, что всё организовано значительно серьёзнее. Может, смогу применить и в своей работе)
В ПЛК популярны диаграммы и функциональные блоки. Но сложные проекты лучше "текстом" писать.
Обратите внимание - этот комментарий, другие комментарии, эта статья, эта страница хабра… оно всё из текста. Да, в случае страницы есть интерфейс, а в статье даже есть картинки. Но всё же задумайтесь - сейчас вы читаете этот комментарий текстом. Почему же никто не пишет комментарии картинками? Вот то то и оно.
Дело в том что мы все имеем опыт в тексте частенько лишь на лет 5 меньше нашего возраста. А самый удобный инструмент тот с которым ты уже давно успешно работаешь, а ещё с ним работают миллионы людей в рамках языка и миллиарды в рамках текста вообще. Если бы мы рисовали картинками слова… то получились бы иероглифы, которые используются также парой миллиардов людей. При этом они также упрощены до штрихов и простых символов. Даже в виде картинок это текст.
Визуальное программирование не эргономично также как написание этого комментария визуальными объектами с линиями - это возможно, но категорически не практично. Не говоря уже о том что на клавиатуре есть куча символов и ввод линеен, как и чтение. А вот с картинкой он многонаправлен, многомерен. Человеческое восприятие конечно может так, но это сложнее.
Картинки конечно нужны. Но они как пояснение. Действительно - некоторые вещи лучше зарисовать. Не хватает языкам программирования дополнений в виде зарисовок либо крупно-архитектурных моментов, либо наоборот микро… с другой стороны рефакторить и усложнять такое по мере развития проекта - это боль. Потому зарисовать в документации это ок, а вот тащить в код - сомнительно. В конце концов сколько существует книг, поставляемых в формате текста без всего, и всё там прекрасно. Лишь некоторые вставляемые иллюстрации, например фотографии. Или опять же те же общие абстрактные схемы.
Текст идеально подходит для описания и понимания. Невозможно создать полноценный язык программирования в визуальном виде по фундаментальным неразрешимым причинам.
Дело в том что мы все имеем опыт в тексте частенько лишь на лет 5 меньше нашего возраста
Тут главное не вспоминать о том, что опыт с картинками мы получаем еще на пару лет раньше текста, а то все дальнейшие ваши рассуждения будут смешно смотреться.
Это можно так до зрительных колбочек дойти и что всё вообще электронные импульсы. Но разговор про универсальные инструменты общения и описания. В том числе описания совсем новой информации.
Для детей трех лет картинки в книге это охренеть, какая новая информация! Все еще слишком слабые аргументы для "фундаментальных причин"
И всё же ваш комментарий всё ещё текстом. Хотя ничего вас не останавливало. На самом деле вы правы в том что не хватает ещё аргументов. И недостающий элемент - голос. Слова от голосового обращения, потом перевод это в визуальное отображение текстом. По сути мы разговариваем голосом через визуальный носитель. И он универсален, в отличие от любых не словесных образов, хотя и там есть плюсы, но об этом я уже писал.
И всё же ваш комментарий всё ещё текстом. Хотя ничего вас не останавливало.
Так я разве топлю за картинки? Не, я тоже за текст. Просто мне конкретно ваши аргументы кажется слабыми.
Кстати, восприятие визуального программирования, так сказать, массами может очень сильно измениться в ближайшие полвека. Если ещё лет десять-двадцать назад в школах программирование учили вяло и именно на классике - т.е. текстом. То сейчас ситуация сильно меняется - в школах активно начинают изучить программирование именно с графических систем, специально созданных для детей - типа Scratch - и это правильно - и это будет закладывать совсем иное и углублённое отношение к визуальным ЯП среди новых поколения - и чем больше будут уделать внимания разным графическим системам именно со школьной скамьи - тем ярче будет желание (как и не желание) - программировать и во взрослой жизни с применением визуальных сред. Но тут уже как душа у кого ляжет - но, всё-таки, некоторое привыкание к визуальному программированию будет с детства, а не так как у большинства нынешних уже состоявшихся программистов - которые хорошо освоили текстовый подход - и смотрят на иные средства как на что-то чужеродно!
Да и сами визуальные ЯП за ближайшие десятилетия, а то и столетие - подтянутся - и будут ещё более удобными, приятными и мощными в использовании - чем текстовая классика - но вряд ли они смогут вытеснить текстовый подход - скорее они его дополнят!
Визуальное программирование существует уже давно и активно применяется. Посмотрите на Houdini, на shading, compositing и geometry nodes в Blender'e, на blueprints в Unreal Engine. Естественно, никто с помощью него не пишет огромные системы. Только небольшие скрипты для симуляций, покраски модели, игрового события и т.д.
У меня тоже есть свой собственный визуальный язык программирования, вот так выглядит:
Описанная в статье проблема в том, что визуальное программирование идеально подходит для data-flow, а его пытаются пихать в control-flow. Равно как и наоборот, программирование сложной DSP-логики чисто текстом это боль и страдания. Нужно просто правильно декомпозировать задачу и выбирать подходящие инструменты, только и всего.
Смутило, что используется термин визуальное программирование, но по сути речь идет о визуальном моделировании.
Из моего опыта, наиболее близко и эффективно применение визуального подхода для получения кода - это ER модели, и Oracle Designer был великолепен в свое время.
Возможно, в будущем визуальное программирование будет как основа, а под капотом будут трудиться нейросети.
Около 20 лет назад я столкнулся с VisSim. Мне показалось это довольно интересным решением. Самое главное, что его отличает от, например, Scratch, это отсутствие привычных конструкций из языков программирования, таких как циклы и переменные. Он состоит из логических элементов, сигналов и ввода-вывода. И в таком, вроде бы урезанном, виде можно реализовать практически любую программную конструкцию. И выносит вполне себе наглядно при этом. Проблема там была с поддержкой железа (только пара вариантов от TI) и очень плохая генерация кода на Си. Можно было обойтись и без генерации, но, опять таки нужны были платы от тексаса.
Вы серьёзно сравниваете симулятор схем с языком программирования?
Это не симулятор схем. И для эмбеддед задач вполне подходит пусть и с некоторыми ограничениями. Я же говорил, что с ее помощью делал прошивку для отладочной платы от тексаса. Вполне себе работало, ввод с кнопок, по ком порту, вывод на компорт и светодиоды. Проблем не было. Почему это нельзя сравнить с языком программирования?
Проблема многих языков визуального программирования в том, что они пытаются заменить собой вообще все операции обычных текстовых языков. В результате это превращается в адский ад.
Как в визуальном программировании будут выглядеть такие штуки:
$a = $b ?? $c + 1;Или, например, элементарный array_map или array_filter:
$filteredValues = array_filter($array, fn(Item $item) => $item->getValue() > $threshold);И вся вот это создает такое количество визуального шума, что за ним теряется процесс как таковой.
У меня просто тоже был подход к снаряду. Я делал конструктор чат-ботов для Telegram. Тоже визуальный, разумеется. Потом мне захотелось интерактивности и гибкости и я туда притащил все фишки визуального программирования, вроде циклов, ветвления, переменных..... А потом я решил сделать текстовую игру.... на 700 сообщений.... с проверками, ветвлениями и т.п. Как это выглядело видно под спойлером.
Визуальное программирование - это просто!
Не адепт визуального программирования. Но из чистого любопытства
$a = $b ?? $c + 1;
Хотя подвариантов представления операций тут много разных может быть (например +1 может быть операцией на стрелке)
Зелёная стрелка - передача значения (операция более приоритетна чем чем просто переход)
Фиолетовая - переход к другому блоку без передачи значения
Синий идентификатор с - случайно - должен быть как b - красный - как просто источник данных
Надписи на строках- условия (! - отрицание, ? - базовое сравнение)
Позже и про маппинг придумаю
Очень много условностей, ИМХО. Вы добавили еще одно измерение - цвет. И это тоже надо будет запоминать программисту.
К тому же представленный пример висит в воздухе. Если его встраивать в большую программу, то куда, будет идти стрелка из предыдущего блока? Кроме того, примеры с $b и $c+1 это были просто примеры выражения. В реальном мире там может быть, например, результат выполнения какой-нить функции. Например:
$a = functionA($param1) ?? functionB($param2);Понятно, что в "нормальных" языках визуального программирования можно реализовывать кастомные именованные блоки (и даже с параметрами). По сути это подпрограммы. Но при этом, ИМХО, теряется вся фишка визуализации.
Очень много условностей, ИМХО. Вы добавили ещё одно измерение - цвет. И это тоже надо будет запоминать программисту
Во-первых, я не добавлял измерение цвет - он здесь, скорее, как подспорье - ведь и в современных IDE текст тоже же не чёрно-белые!
Во-вторых - мы же переходим от текста к графике - а тут уже активно в ход идут разные средства визуализации - иначе - зачем нам графика?
Но при этом, ИМХО, теряется вся фишка визуализации.
Наверное Вы слишком зашорены в понимании что есть визуализация при программировании - а я выше сразу дал замечание - что представлений может быть много. И много представлений могут быть реализованы в одном решении.
В тех же текстах ведь тоже, скажем, есть группировки - сворачивания блоков - и ничего - не шибко люди возмущаются "что теряется всё преимущество текстов" - да и настраивается это гибко...
то куда, будет идти стрелка из предыдущего блока?
В примере выше входящая стрелочка должна указывать на левый блок "b" - это же очевидно!
Кроме того, примеры с $b и $c+1 это были просто примеры выражения. В реальном мире там может быть, например, результат выполнения какой-нить функции
Как я считаю - всё-таки писать выражения при визуализации можно несколькими путями - для удобства:
Как в примере выше - прямо внутри блока - удобно для простых выражений, например математических вычислений
Писать через соединения блоков стрелочками-операциями (показано в примере ниже для "+")
Писать через блоки-операции (показано в примере ниже как вызов функции или приведение типа)
Может ещё какие варианты могут быт...
При этом - все варианты должны быть взаимозаменяемы автоматическим рефакторингом- по необходимости. А сложные вычисления ещё должны быть и реализуемыми в виде подблока (подпрограммы) - по умолчанию свёрнутой, открываемой отдельно как функция (ниже в примере это может быть внутри нижнего блока справа - свёрнутого второго вызова функции "functionA").
Ваш же пример ниже:
$a = functionA($param1) ?? functionB($param2);
Опять же - это проcто один из вариантов. И я не претендую на эффективность и красоту - я не адепт визуального программирования
Примечание:
+/- сворачиваемый блок
Лупа - открывает детали реализации (вообще-то - предполагается открытие в отельном попап (или, скорее, плавающем) блоке, или даже окне - но тут, для наглядности (и упрощения моего рисования), рисую сбоку) - точечная линия от лупы - появляется только при раскрытии - или ещё может не быть вовсе
В этом примере некоторые операции представлены внутри блоков (например приведение типов), некоторые на стрелочках перехода
Пунктирная стрелочка справа - автоматическая - визуализация возврата значения функции
Возможно, в блоках вызова функций тоже стоит показывать фактические типы (но это всё может быть настраиваемым) - раз это типизированный ЯП
По-хорошему, в реализации функции "functionB" на стрелочке передачи результата сложения Arg2 нужно отобразить в какой параметр передаётся это значение, хотя бы автоматически - если у функции только один обязательный параметр (однозначное соответствие) - для наглядности визуализации
Аналогично могут передаваться какие-то аргументы и в исходные вызовы функций "functionA", "functionB" - но это необязательно - т.к. логика переходов может быть совсем от других источников (как переход от функции "functionA" к функции "functionB)" - но всё-равно можно был бы сделать вторичные, "висящие" блоки передачи аргументов. Но, данный синтаксис визуализации этого не требует - хотя это можно создать автоматически рефакторингом для наглядности
Ошибся в обязательных параметров функции "functinonB" - пусть Arg2 тоже имеет какое-то значение по умолчанию - лень перерисовывать! Прошу прощение - это не существенный огрех
Кстати, очень интересной фишкой может стать раскрытие реализации вфункции "functinonB" сразу в переданных аргументах а не в параметрах
Так в чём сложность создания или восприятия?
Тут только некоторые трудности у платформы по эффективной визуализации будут!
Так в чём сложность создания или восприятия?
Вот даже в примере визуализация занимает в разы большую площадь, если сравнивать со строкой. Соответственно, вообще на экране меньше логики помещаться будет, которую можно окинуть взглядом и помедитировать, не трогая управление отображением.
Вот даже в примере визуализация занимает в разы большую площадь, если сравнивать со строкой.
Конечно - поэтому я и не адепт визуализации - изложил свои аргументы выше в комментариях - но это не значит что, относительно эффективно, визуализировать вообще нельзя - Вы спросили как будет выглядеть - я показал один из вариантов. Остальное дело привычки и дело вкуса
Касаемо красоты под спойлером, это всё - функции? Или структура диалогов? Почему не поделить на отдельные секции? Спрятать под капот, использовать функции и макросы, вызовы событий... решения есть. И чем больше я изучаю визуальное программирование, тем меньше становятся подобные схемы. Так сказать, перехожу на уровень выше.
Это отдельные сообщения. И тут еще управляющих конструкций особо нет, просто сами сообщения и кнопки под ними. Понятно, что надо группировать сообщения в линейные сценарии и запускать сразу сценарий, вместо длинной портянки сообщений, но не потеряется ли тогда "визуальность".
А если делать не визуально, то я бы это всё запихнул в JSON или в YAML, добавил каких-нибудь управляющих инструкций, написал простенький парсер этого конфига и оно бы прекрасно работало. И править было бы намного удобнее, честно говоря.
Возможно, визуальность и правда потеряется. Но, на мой взгляд, что в обычном коде, что в визуальном, читабельность и понятность одинаково важны и достигаются схожими методами)
То есть, для меня, скажем, будет одинаково трудно понять, что делает код, если он состоит из 1000 строк или если тот же самый код показан через визуальные ноды и этих нод 1000.
А вот если код разбит на функции и каждая такая функция помещается на экране - разобраться в ней будет проще, как в визуальных нодах, так и в текстовом виде.
Что забавно, и в обычном коде и в нодах мне очень помогает разделение по цвету и по блокам (через комментарии).
$filteredValues = array_filter($array, fn(Item $item) => $item->getValue() > $threshold);Чисто такой пример мог бы выглядеть так
Грифельного цвета блок - это анонимная лямбда с одним аргументов (автоопределяемый по контексту тела), и одной переменной в "замыкании"
Но выглядит то всё не очень красиво - поэтому ниже картинка с 4-мя вариантами более эффективного визуального представления данной операции:
Слева направо:
Значение переменно "array" передаётся в переменную с условием, наложенным через зарезервированное слово "item" - что говорит, что его надо наложить на элементы внутри потока "array", вторым аргументом сравнения идёт другая переменная - т.к. условие написано на стрелочек, здесь нет стрелочки передачи сюда этой переменной из блока
Зато в этом примере передаются обе переменные - здесь применятся отдельная операция сравнения в блоке условия, так же через обращение к элементам массива "array" через зарезервированное слово "item" (в принципе, наверное можно сделать и отдельный блок сравнения - который всегда оперирует только внутренними элементами передаваемого в него потока, тогда применять "item" будет не нужно)
Вот, примерно как тут, только тут мы сразу определяем обращение к переменной "array" как блоку развёртывания потока - на выходе уже будет идти только поток элементов "array" (т.е. сами "item"), поэтому тут на стрелочке условие уже упрощено - только оператор сравнения и второй аргумент сравнения
Здесь аналогичный подход - только применён блок преобразования (в данном случае фильтрации), с условием прям в самом блоке, поэтому на выходе уже будет отфильтрованный массив, который и передаётся далее в переменную-приёмник
Лично мне нравится 4-ый (правый) вариант - но в нём нужно определять блок источника; а если нужно переходить из другого, уже имеющегося, блока (без определения нового - хотя это тоже возможно) - то нравится первый (левый) вариант (здесь источник, в лице блока "array" может быть определён как угодно - это не влияет на решение, главное - его тип данных должен быть перечислимым).
Безусловно, это далеко не все возможные эффективные визуализации фильтрации одной переменной по условию для помещения результата в другую переменную.
Применение ссылок на источники (переменные) внутри выражений блоков или стрелок достаточно компактно и легко читается, но тут есть недостаток, в отличии от ссылки с другого блока - ссылка более гибкий механизм, т.к. в этом случае зависимый блок не зависит напрямую от выражения исходного блока - и его можно легко менять, не трогая зависимые блоки! Но насколько это принципиальное преимуществ - я не знаю! Но - все варианты записи должны быть иметь возможность лёгкого применения авторе факторинга друг в друга - так что это вообще не проблема - а ли8ь разные представления одного и того же!
А теперь посмотрите у кого представление получилось более красивым, понятным, компактным и эффективно воспринимаемым и видоизменяемым?
Впрочем... я и текстом могу написать такие варианты тоже весьма эффективно и компактно:
filtredValues <- From array Filter (item>threshold)
array -> Filter (it>threshold) -> filtredValues
(array) -> if(item>threshold) -> filtredValues
array:(item>threshold) -> filtredValues
Все 4-ре примера выше приведены в синтаксисе разрабатываемого мною ЯП 5-го поколения под рабочим названием "ODIN") - надеюсь разберётесь - всё же просто:
-> и <- это операторы направления потока данных
(источник) это операция начала извлечения (перечисления) элементов источника (может быть ещё так: (elm<-array) если нужен свой идентификатор для элементов источника - но это нужно при вложенных перечислениях
Filter это команда - принимает на вход источник и возвращает обработанный источник (it - зарезервированное идентификатор - ссылающийся на внутреннюю реализацию команды - по сути там лямбда)
Двоеточие - это операция преобразования - в данном случае с вложенным в скобки выражением фильтрации с обращением череp item - к содержимому источника)
array:(item>threshold) -> filtredValues
можно написать и так короче (но, на мой взгляд, менее наглядно):
filtredValues <- array:>threshold
или так (как аналог и для (array) -> if(item>threshold) -> filtredValues):filtredValues <- (e<-array, e>threshold)
или (тут цепочка преобразований может быть ещё продолен с доп ":" справа, и можно обращаться к "e" - исходное значение; просто сами выражения перечислений могут быть куда более сложными):
filtredValues <- (e<-array):(e>threshold)
Я это всё как раз к тому - что я сильно настаиваю, что текстом писать можно и компактнее эффективнее - и именно этот подход и надо развивать в будущих ЯП
Вот диаграмма сгорания задач, сгенерированная Hercules CLI:
Количество строк кода и годы вижу, а понять смысл не могу. Это визуализация того сколько кода с каких времён в проекте осталось? Или что?
грех здесь инструмент yEd не упомянуть
У визуального программирования есть пара интересных архитектурных преимуществ - перед текстовым:
Очень удобно управлять множественными потоками данных - в т.ч. ветвлениями или дублированием (см. пример ниже). От одного источника легко может исходить несколько переходов. И на эти переходы можно удобно накалывать разные условия или метки аннотаций - задающие логику работы. Более того, на источник и на приёмник можно вешать как бы специальные порты - проекции/фильтрации - так что все исходящие или, соответственно, входящие линии переходов, из/в эти порты, будут подвержены зависимы от действий, заданных в этих портах - и на один источник/приёмник можно повесить сразу несколько разных портов! Так же, множественные переходы могут удобно определять и параллельное выполнение этих операций (в т.ч. в режиме по умолчанию, когда компилятор сам решает как лучше выполнять эти действия - в отдельном потоке или последовательно - в зависимости от настроек контекста выполнения и специальных хинтов-аннотаций со стороны программиста)
В отличии от представления инструкций/деклараций в текстов - которых по сути линейны - графические схемы размещаются на плоскости - а, в принципе, в 3D и даже в большем числе измерений - что позволяет более наглядно размещать связи между элементами и вложенные блоки. Тут же можно сказать и про уровень масштабирования - когда можно приближая масштаб легко переходить от общего узла некоторого блока - к его внутренней реализации, оставаясь в текущем контексте, что позволяет (при необходимости), например, вместо внутренней логики подпрограммы (читай функции) подставлять идентификаторы текущего контекста - чтобы лучше понимать как внешняя среда влияет на результат внутренней
В схеме выше много действий. Условно начало можно считать получение фильтра FilterList (хотел сначала сделать точку входа Request - но передумал - и так сложно вышло)
Ключевым тут является источник переменной "A" (тип который является перечислимым) - у неё есть ряд исходящих портов разного типа - какие-то передают все данные переменной "A" (но только если сущность переменной "A" удовлетворяет условиям); какие-то передают только часть её содержимого - поэлементно удовлетворяющие условию. Так же тут осуществляются операции фильтрации данных по типам и контрактам (забыл добавить и просто операции преобразования)
Есть даже паттерн переназначения фильтра по умолчанию (он не изменяет передачу типа данных, но все условия на него, накладывается согласно заданного шаблона)
Короче - схема, безусловно очень абстрактная, но я просто хотел показать возможную глубину фишек визуального программирования на графических схемах
Это все хорошо, пока граф хотя бы приблизительно планарный (я вот на схеме всего одно самопересечение насчитал). Если оно не так (а не планарный граф без самопересечений не раскладывается) - то схема превращается в совершенно невнятную "кучу спагетти"
Есть одно пересечение от функции "Process" к "B" (в идеале там должно быть "мостик" - рисовал в ""Miro" - не поддерживает, видимо) - но, замечу, что как раз в этой схеме его можно избежать, нарисовав линию стрелки в другую сторону (обогнув функцию "Process2")! Кстати, IDE может иметь средство перераспределения схемы/части схемы - для минимизации пересечений.
В более сложных схемах могут применяться разные способы избежание пересечений или решения проблем их читаемости. Например, можно клонировать состояние системы в узле "А" (переменной/источнике/примёнике) - и нарисовать его ниже отдельно - так чтобы его связи не мешали другим. Или размещать их на разных слоях (в т.ч. с настроенной прозрачностью или цветами линий - чтобы даже в неотображаемом или полуотображаемом случае видеть намёки, что тут есть и другие связи). Можно и сами линии группировать через промежуточные узлы - и начинать из них движения тоже где-то ниже. Можно просто часть линий выносить в узел субпрограммы, который в основном режиме отображается как просто узел, а при детализации (как написал выше - это легко делать просто масштабированием схемы, ну или просто кликом по лупе в этом узле) - уже отображать отдельно его структуру. И так далее и тому подобное - вариантов как синтаксических так и средств IDE может быть много! Не думаю, что это такая уж проблема. Тем более, что я, ту не требую целостности графа, а в большинстве случаев такого большого числа переходов из одного узла вряд ли будет - на картинке уж очень специфическая ситуация - чаще всего инструкции достаточно линейны (ветвления условий и матчей - скорее всего не будут шибко обширными или хорошо сворачиваются, по указанным выше, или иным, методикам), а распараллеливания - вполне можно достаточно эффективно разнести друг от друга.
Кстати, IDE может даже представлять схему в разных вариантах компоновки - просто меняя способы её отображения (фактически не переставляя сами элементы) - что позволяет легко подстраивать её анализ под разные ситуации
Главное преимущество визуального программирования - отсутствие необходимости именования переменных/объектов и ещё больше возможностей для инкапсуляции.
Вот ещё один пример - синтезатор, на котором можно играть как с миди-, так и с обычной клавиатуры. При этом звук идёт одновременно на два разных устройства - один допустим в зал, другой в монитор. И обратите внимание - графической связи между клавиатурами и синтезатором нет, она задаётся в свойствах:
А теперь давайте посмотрим, сколько то же самое займёт текстом:
var vsti = new VST("c:\\vst\\yamaha\\syxg50.dll");
var kbd = new KeyboardInput();
kbd.KeyPressed += OnKeyPressed;
var midiin = new MidiIn();
midiin.MessageReceived += OnMessageReceived;
var wasapi1 = new WasapiOut("Динамики (Realtek High Definition Audio)");
wasapi1.FillBuffer += OnFillBuffer1;
var wasapi2 = new WasapiOut("LG ULTRAGEAR (Аудио Intel(R) для дисплеев)");
wasapi2.FillBuffer += OnFillBuffer2;
...И это просто объявление объектов, без какой-либо обработки миди-сообщений и копированию данных из одного буфера в другой (и хорошо если эти буферы будут одного размера). А чтобы в визуальном редакторе создать объект - даже контекстное меню вызывать не потребуется, потому что для каждого объекта предусмотрено клавиатурное сокращение, например "kbd" или "midiin", после чего он появляется в позиции курсора.
del
Главное преимущество визуального программирования - отсутствие необходимости именования переменных/объектов и ещё больше возможностей для инкапсуляции
Я бы назвал это преимущество весьма сомнительным. Да - можно - но много ли от этого толку... а сколько это в итоге порождает проблем в сложных схемах... Насколько это поддаётся эффективной и продвинутой отладке... Насколько это всё само документируемо, и поддаётся созданию отдельной документации...
Поэтому в своё примере выше - у меня все узлы именованы (кроме узлов проекций/фильтров - это порты, принадлежащие своим узлам, но - в принципе им, как и линиям тоже можно было бы вешать лейблы)! А так - как, в другом комментарии выше, я показывал - можно и анонимную лямбду создать - и передать её в другой блок!
И обратите внимание - графической связи между клавиатурами и синтезатором нет, она задаётся в свойствах
Да, при визуализации вполне допустимо - но, опять же, очень спорное решение - усложняет понимание схемы!
А насчёт примера.... ну я тут выше в комментарии уже приводил примеры своего ЯП для музыки "ORANGE" - он текстовый и на нём ваш пример (в котором, правда большая часть информации отсутствует в обоих вариантах представления) выглядел бы так:
пишу целиком, включая шапку, без особых синт. сокращений:
project MyProject
{
device OutputDevice1
{
Direct = Output //Не обязательно - т.к. это по умолчанию так
Format = MIDI
Driver = WASAPI(Динамики (Realtek High Definition Audio)"
ChanelsMap = {Left->"L", Right->"R", BackLeft->"BL", BackRight->"BR"}
}
device OutputDevice2
{
Direct = Output //Не обязательно - т.к. это по умолчанию так
Format = MIDI
Driver = WASAPIOut("LG ULTRAGEAR (Аудио Intel(R) для дисплеев)") ChanelsMap = {Left->"L", Right->"R"} //Не обязательно - т.к. это по умолчанию так (когда у устройства нет других каналов)
}
device InputDevice1
{
Direct = Input
Format = MIDI
RAWFormat = Int
RAWConverter = System.Converters.ToMIDI.KeyboardScanCodeToMIDI Driver = KeyboardInput //Если я правильно понял – что источников является букво-цифровая клавиатура
RAWInternalConverter += @AnotherFunction //Если нужен какой-то свой обработчик конвертации потока кодов клавиатуры в MIDI инструкции
ChanelsMap = {Mono->"1"}
}
device InputDevice2
{
Direct = Input
Format = MIDI
Driver = MIDIInput("LoopBe Intenral") //Какой-то MIDI input - из примера не ясно как он настроен
ChanelsMap = {Mono->"1"}
}
chanel OutputChanel1
{
Direct = Output //Не обязательно - т.к. это по умолчанию так
Format = MIDI
Space = STEREO //Не обязательно - т.к. это по умолчанию так
Destination = OutputDevice1
ChanelsMap = {Left->Left, Right->Right} //Маппинг только в два канала устройства воспроизведения
}
chanel OutputChanel2
{
Format = MIDI
Destination = OutputDevice2
//ChanelsMap = {Left->Left, Right->Right} //Не требуется, т.к. тут маппинг по умолчанию в два доступных у устройства канала
}
chanel InputChanel1
{
Direct = Input
Format = MIDI
Source = InputDevice1
}
chanel InputChanel2
{
Direct = Input
Format = MIDI
Source = InputDevice2
}
sampler S_yxg50_Sampler
{
Format = VSTi
Path = FilePath("c:\vst\yamaha\syxg50.dll":raw)
Space = STEREO //Не обязательно - т.к. это по умолчанию так
ChanelsMap = {Left->"01", Right->"02"}
}
instrument S_yxg50
{
Destination = S_yxg50_Sampler
Program = 8 //Вообще инструмент подразумевает фиксацию программы синтезатора здесь (т.к. именно инструмент определяет настройки звучания), но в примере она фиксируется только для одного Midi input (вероятно у другого - другая программа) - такое тоже возможно (здесь только значение по умолчанию)
}
layer MainLayer
{
track Track1
{
use instrumnet S_yxg50(ProgramFixed=true)
use input InputChanel1
use output [OutputChanel1,OutputChanel2] //В моей схеме не семплер подключается к каналам вывода, а музыкальный трек (здесь подключение сразу к двум каналам
runtime input:loop //трек активен только в runtime режиме в бесконечном цикле воспроизведения
}
track Track2
(
Instrumnet=S_yxg50(Program=3, ProgramFixed=true) //Сменили программу (тут будет клон инструмента)
Output = [OutputChanel1,OutputChanel2]
) @RuntimeInput(lnfinity) //аннотация режима исполнения трека
}
Layers=[MainLayer]
}
run MyProject
Надеюсь ничего не забыл, и правильно понял исходный пример. Да - может код несколько многословен - но тут много базового конфигурирования идёт. У Вас же, в визуальной части, настройки делаются в узлах - и не отображаются, но их всё-равно надо делать (текст тоже можно скрыть в сворачиваемых блоках, распихать по файлам и подключаемым модулям библиотек, в т.ч. для повторного использования), ну и текст легко комплексно просматривается, и легко рефакторится, и легко публикуется и передаётся куда-либо, да хоnть в Git
И да - всё-таки ЯП ORANGE хоть и спроектирован для реализации runtime MIDI-ввода - но, всё же, создан больше для кодирования воспроизведения в виде инструкций к семплерам (что можно делать и в runtime; или направлять MIDI инструкции из источника в генератор кода в инструкциях ЯП Orange)!
потому что для каждого объекта предусмотрено клавиатурное сокращение, например "kbd" или "midiin", после чего он появляется в позиции курсора.
Ну - для этого возможны:
Шаблоны быстрого ввода в текстовом процессоре IDE (в т.ч. привязанные к macros и static instument generators, которые могут читать конфигурацию из внешнего config-файла, а так же иметь доступ к AST-дереву выражений проекта - чтобы генерировать код максимально гибко и адаптивно; но я не говорю - что такое в принципе нельзя сделать при визуальной разработке - но инструментарий IDE должен быть очень продвинутым, в отличии от текстовых процессоров - где это либо уже реализовано, либо легко подключается плагинами, либо вообще решается на уровне компилятора и/или внешнего текстового препроцессора)
Просто готовые преданстроенные функции внутри проекта или во модулях библиотек - которые просто можно вызвать (в т.ч. с параметрами) - а они уже проведут всю общую настройку - в этом преимущество классического подхода кодирования исходников - в гибком повторном использовании кода (но я не говорю - что такое в принципе нельзя сделать при визуальной разработке)
Да, при визуализации вполне допустимо - но, опять же, очень спорное решение - усложняет понимание схемы!
Ну вот тут кто-то жаловался на спагетти - так это спорное решение разгружает спагетти. И при желании можно отдельную визуализацию таких связей сделать, если уж на то пошло. Ну а задание через параметры потому, что не каждый модуль может выступать в качестве синтезатора, а только тот, кто поддерживает соответствующий интерфейс. И в выпадающем списке ничего лишнего не будет.
на нём ваш пример (в котором, правда большая часть информации отсутствует в обоих вариантах представления) выглядел бы так:
И вы хотите сказать, что эта простыня текста проще в понимании и набивается также в течении максимум десяти секунд?
Эта простыня обычно проще в понимании "а чего тут у нас изменилось с прошлой версии"? Потому что вот это средство визуального программирования - diff показывать умеет? А как это выглядит?
В контроле версий потребности пока не возникало, но за идею спасибо. А diff конечно же можно сделать - хоть текстом, хоть графикой. Внутри же это самые обычные .NET объекты, через рефлексию можно запросить значение полей и сравнивать их. Через ту же рефлексию весь этот граф можно привести к полностью текстовому виду с абсолютно идентичной функциональностью, в будущем планирую реализовать.
Про повторное использование кода, кодогенерацию и шаблоны, и разбиение по файлам/модулям - я уже написал выше. И уверен - даже незнакомые с построением DSP-плагинов люди, сходу поймут что да как тут происходит и настраивается! Не говоря уж про строки комментариев - и прочее самодокументированние!
Да и ЯП "Orange" - задуман как куда более мощная "штука", чем просто DSP-фильтр - так что тут есть "место" для боллеплейт-кода - но всё это можно вынести в повторноиспользуемый код -или применять шаблоны! Да и с некоторым "синтаксическим сахаром" это всё можно несколько было упростить - для простых случаев
P.S. Хотя компиляция проекта в DSP-фильтр или VST-плагин - тоже вполне возможна
А я уверен прямо в обратном. Но для разрешения этого спора конечно же нужно мнение со стороны. Несмотря на то, что мой проект пока ещё закрытый, я его использую для вполне реальных проектов. Например, если вы вобъёте в гугле "foobar subwoofer", то первым результатом скорее всего будет ссылка на мой плагин. Что сможете противопоставить взамен?
Я ни разу не говорил, что Ваше решение - не рабочее и не может иметь практической ценности или быть популярным в определённых кругах. А так да - только практическое применение и отзывы могут показать эффективность того или иного подхода. У меня пока нет рабочего решения :-(
Собственно написал (построил) в среде LabView свою IDE автоматного программирования с применением конечных автоматов (FSM), когда вместо скрипты клиенты применяют инструкции, что по сути является софт контроллером с панелью построения сценария, есть немало реализованных проектов в разных сферах. Коммерческое наименование IDE во избежание бана не сообщаю.
Та к примеру для торгового робота по производству прохладительных напитков из свежезамороженных фруктов и ягод в прототипе задействовано 265 инструкций обращения к I/O.
Для составления инструкций алгоритма работы в среде требуются знания не столько в программировании, сколько в знаниях внешней аппаратной части бинарной логики управления.
Для составления инструкций алгоритма работы в среде требуются знания не столько в программировании, сколько в знаниях внешней аппаратной части бинарной логики управления.
Скажу так - в этом конкретном случае лишь три проблемы:
Отсутствие правильно архитектурно подготовленных библиотек и документации к ним
Отсутствие настроенных кодогенератор, отладчиков и прочего суппорт-софта для данной среды
Закостенелость мышления технического руководства
Отсутствие правильно архитектурно подготовленных библиотек и документации к ним
Если это сказано в сторону LabView, то то изобилие тулсов с их компонентами, не говоря о контекстных хелпах с рабочими офлайн или онлайн примерами на сервере NI, не имеет ни одна скрипт IDE.
Отсутствие настроенных кодогенератор, отладчиков и прочего суппорт-софта для данной среды
И опять пустой выстрел в воздух. Так как каждый модуль тулса, это многократно выверенный код, написанный на плюсах, который прежде чем пройти преобразование в графический компонент и получить право на его размещение в логическом ядре LW, проходит строжайшее тестирование, которому могут позавидовать иные библиотечные DLLы.
О супорт софте с LW не может сравниться ни одна скрипт среда, т.к. помимо кучи инструмента внедренного для таких задач, там так же имеется возможность и встраивания скрипт текста, ежели Вам так угодно.
Что касается отладчиков, то этот термин в среду LW, Вы притащили за уши, простите за прямоту. У вас никакая функция или процедура не будет воспринята применяемой, еще на этапе ее построения и система просто не позволит ее запустить для такого понимания, больше того Вы тут же можете обратиться к хелпу и примерам с рекомендациями в какую сторону нужно рулить.
Закостенелость мышления технического руководства
По личному опыту закостенелое мышление руководства, если конечно оно не спитое не обкуренное и т.п. лечится демонстрацией желаемого результата, хорошего или плохого, это уже как Вам, кодеру нравится, но все же результату, а не угару скрипт кодеров, у которых наметился тотальный обвал...
К сожалению - все Ваши ответы - выстрел в воздух... ибо говорил я совсем о другом, и не смотрел пристально в стороны LabView - а мысли более обобщённо!
Говоря о библиотеках - я говорил и узкоспециализированных (но, впрочем и об обобщённых - но при условии, когда архитектуре выстраивается от частного конкретного - к общему абстрактному, но очень гибкому, чтобы можно было в сановном логику выстраивать через общие абстрактное - чтобы применять обобщённые библиотеки) прикладных библиотеках для торгового робота (или какой ещё специализированной прикладной системы)! Ну и они должны быть хорошо задокументированы (в том числе, хотя бы, самодокументированы).
Говоря о кодогенгераторах - я имел в виду глубину перехода от абстракций - к конкретным инструкциям! Чем круче база статических анализаторов и кодогенераторов - тем менее системный алгоритм надо писать - удаляясь от внутренней технической части робота или иной прикладной системы, и тем больше модно сосредоточиться на общей прикладной логике и процессах взаимодействий сложных узлов и людей!
Говоря об отладчиках - тут я не понял Ваши мысли. Может пояснить? Я говорил - что прикладной код должен сейчас, и тем более в будущем, иметь высокую способность к глубокой и высокоуровневой отладке - чтобы экономить время разработчика и повышать его информируемость! И тут я уже говорил - что у визуального представления есть свои некоторые полезные фишки для этого - но я подчеркну, что ради них нет смысла именно программировать визуально - достаточно получить построенную визуальную модуль алгоритма по иному формату описания, каким бы он ни был!
Говоря о тулзах - сейчас в IDE и текстовых процессора саммые продвинутые суппорт тулзы - по вводу анализу, рефакторингу, версионирования, прогнозируемого автоввода, автоисправления, шаблонизироания и динамического применения паттерном для текста и т.д. и т.п. визуальным средам до этого ещё расти и расти... это просто пропасть! Но... это не значит что визуальные системы не смогут это всё наверстать (но это титанический будет труд). Другое дело что на это всё уйдут не годы... минимум десятилетия а скорее всего столетия - за это время и текстовые процессоры, и, уже тем более, какие-то иные средства ввода и манипулирования информацией - дадут ещё больший скачок вперёд - т.к. пока они на пике прогресса - и большая часть людей сосредоточит свои умы именно на их развитии - и если случится устойчивый перелом - то на то, чтобы он набрал кульминационный темп - потребуется уйма времени - ибо ломка мышления и парадигм будет страшная!
Поспешил - ошибки допустил - что сам уже заметил:
Была проращена открывающая кавычка:
Driver = WASAPI("Динамики (Realtek High Definition Audio)"Опечатка "instrumnet"->"instrument"
В обоих OutputChanel ошибочно указал формат MIDI - там, конечно же WAVE - но может быть и MIDI - но тогда VSTi семплер будет проигнорирован (если он не сможет выдавать MIDI поток)
В "Track2" забыл указать параметр "Input=InputChanel2" для настройки канала, по которому в трек будут поступать MIDI события!
При старте проекта хорошо было бы указать и стартуемые треки, ну или аннотировать их как автотстартуемые вместе с проектом (а вообще треки могу запускаться (и останавливаться) в произвольный момент времени - мануально, по расписанию, по событию и другими способами - тут полная гибкость):
run MyProject with track(Auto) [MyLayer.Track1, MyLayer.Track2]У значений перечислений без указания полного пути идентификатора - по-хорошему надо бы поставить точку перед идентификатором значения - чтобы синтаксический разбор понимал, что надо проанализировать тип приёмника для идентификации полного имени значения - но, будем считать, что можно и без точки, когда нет пересечений идентификаторов в текущем контексте - опция настройки проекта)
Примечания:
Маппинг каналов скорее лучше делать через отдельный компонент Mixer - но для простоты не стал его указывать - а вообще - в мультиканальном проекте с пространственным 3D0звучанием такой компонент может активно применяться!
Вместо указания параметра инструмента "ProgramFIxed" (что скорее для инструментов, которые не поддерживают разные программы звучания) лучше настроить у InputChanel компонент фильтра - для отбрасывания MIDI инструкций смены инструмента:
Пример фильтрации в каналах
chanel InputChanel1
{
Direct = Input
Format = MIDI
Source = InputDevice1
Filter = MIDIBoolFilter
{
return MIDIEvent.Command != ProgramChange)
} //Задали произвольный алгоритм фильтра MIDI сообщений - пропускаются только "истинные" MIDI события
}
chanel InputChanel2
{
Direct = Input
Format = MIDI
Source = InputDevice2
Filter = MIDIEventFilter
{
return ? (MIDIEvent.Command == ProgramChange) MIDIEvent:new{Command=None}
} //Задали произвольный алгоритм фильтра MIDI сообщений - подменяющий сообщения по смене программы на пустую команду (в условии нет секции "иначе" - она генерируется автоматически - исходным значением событий); а, в принципе, такой фильтр может и другие преобразования делать (для WAVE-формата канала тоже свои фильтры могут быть - но там, их лучше подключать как DSP-процессоры - между каналами)
}
Filter = MIDIBoolFilter
{
return ? (MIDIEvent.Command==ProgramChange) MIDIEvent:{Command=None}
} //Задали произвольный алгоритм фильтра MIDI сообщений - подменяющий сообщения по смене программы на пустую команду (в условии нет секции "иначе" - она генерируется автоматически - исходным значением событий)
Музыкальный трек организован куда сложнее - чем показано в данном примере - он может обслуживать мульти-инструменты, мульти-эффекты, полифонию, мульти-семплирование, мульти-каналы и т.д. и т.п. По сути - трек - это просто некоторая агрегация сервиса воспроизведения (как и слой, как и, не указанный здесь, score - для разделения партитур) - все они определяют свой контекст воспроизведения
Поспешил - ошибки допустил - Была пропущена открывающая кавычка:
Driver = WASAPI("Динамики (Realtek High Definition Audio)", опечатка "instrumnet"->"instrument" ...
Это, кстати, ещё одно преимущество визуального программирования - ошибки подобного рода там невозможны в принципе.
Тут всё зависит от подходов к разработке и среды. Чем жёстче подходы - тем меньше комфорта и универсальность - но выше контроль.
А подобные опечатки текстовые IDE в 99.98% случае сами находят ещё на стадии окончания ввода слова! А некоторые продвинутые IDE ещё и сразу могут исправлять! Не говоря уже о быстрых подсказках автоподстановки - которые в умелых руках (и умелом текстовом процессоре) в более чем 80% случае просто позволяют избегать таких ошибок!
(не ключевые слова, уже определённых идентификаторов или литералов - так же будут выделяться цветом; а при мало-мальски грамотном назначении имён идентификаторов - вероятность ошибиться и из-за опечатки ввести другое имя существующего идентификатора - практически равна нулю - и современные IDE могут сразу автоматически исправлять такие опечатки)!
У визуальных сред куча своих проблем - часть я в комментариях к этой статье уже описал - но это далеко не полный список!
То же зарезервированное слово для определения сущности "instrument" - в текстовом редакторе вводится за 1.5-2 секунды (кото-то и быстрее введёт, я уж не говорю о шаблонах и копипасте, и быстрых подсказках ввода) - ошибка в тестовых процессорах будет видна сразу (это же ключевое слово - оно не будет выделено соответствующим образом) - и на её осознание и исправление (требующееся очень редко) уйдёт ещё секунды 2-3.
А сколько времени уйдёт в визуальном редакторе размещение такого компонента на поле (так оставим в стороне вспомогательные средства быстрого ввода): надо где-то нажать кнопку с командой добавления компонента, затем выбрать его из списка, или воспользоваться текстовым поиском, кликнуть по кнопке добавления, перенести его в нужное место на плоскости (а то ещё и другие компоненты подёргать) - это десятки секунд.... а потом окажется что это не тот компонент, что нужен (например, промахнулись - не туда кликнули)...
То же и про пропущенную кавычку - обычно это всё легко видно - небольшие сложности только в интерполяционных строках бывают - но были бы такие у Вас - были бы такие же проблемы, скорее всего - но это всё мелкие проблемы - и быстро исправляются.
P.S.
Вот опечатка с MIDI там где нужна WAVE именно в моём ЯП всплыла- бы только при компиляции - когда драйвер устройства WASAPI не смог бы по типам данных спрячься с типом данных, передаваемых из канала! Но это уже нюансы ЯП гибкой статической типизации - точные типы появляются только при компиляции!
Упущенный параметр "Input=InputChanel2" для "Track2" (без специально настроенных анализаторов) всплыл бы только при отладке - параметр не обязательный (как и то, что у трека может не быть входного канала данных - когда он сами их статически описывает или генерирует, или откуда-то загружает) в своём теле - внутри { }; или в трек могут напрямую отправляться инструкции из другого трека (трек сначала может динамически наполняться, а потом только воспроизводиться, или не обязательно воспроизводиться, а, скажем, выгружаться на диск в файл/БД, или передаваться в другую программу, в т.ч. по сети)!
Пропущенное указание треков, которые надо стартовать при старте проекта - это скорее нюансы дизайна ЯП - может действительно не надо стартовать никаких треков - а при старте проекта нужно выполнить сначала подготовительные алгоритмы... но можно, конечно ввести какую-то конструкцию - указывающую на это - и когда ничего нет - хотя бы выдавать предупреждение при компиляции
А сколько времени уйдёт в визуальном редакторе размещение такого компонента на поле (так оставим в стороне вспомогательные средства быстрого ввода)
Так оставляйте в стороне и вспомогательные средства IDE для быстрого ввода в виде автодополнения, подсветки синтаксиса и проверки орфографии, а то как-то нечестно получается.
Так оставляйте в стороне и вспомогательные средства IDE для быстрого ввода в виде автодополнения, подсветки синтаксиса и проверки орфографии, а то как-то нечестно получается
Если внимательно читали - то я при оценке времени так и сделал. И указал - что с данными средствами будет и ещё быстрее и надёжнее
Просто Ваш аргумент он не имеет значимой силы
Интересно - кто минус моему комментарию выше поставил - за что (если это вы просто в отместку - то я не минусовал ваш комментарий)
Ваш аргумент он не имеет значимой силы
Этот аргумент не для вас, а для других. Понятное дело, что вы будете топить за свой ЯП всеми правдами и неправдами. И сути это не меняет - нельзя ошибиться в названии переменной, если его нельзя напечатать, а можно только выбрать из списка. Нельзя ошибиться с пропущенной кавычкой, если кавычек тоже нету. Нельзя перепутать "=" или "==" в условии, если "=" тоже нету. Нельзя ошибиться с разыменованием NULL в рантайме, если NULL-ов тоже нету (а вместо них есть значения/объекты по умолчанию).
Понятное дело, что вы будете топить за свой ЯП всеми правдами и неправдами.
Я не собираюсь топить за свой ЯП! Как и топить другие системы (ну кроме Native instruments Kontakt - уж больно она меня разочаровала (хотя шутка, бесспорно, полезная); как и разочаровало, например, и развитие Sony Acid - который теперь мультикомбайн Vega, Cakewalk - который теперь Sonar (и многие другие мультидорожечники) - но это для тех кто в курсе). И готов принять любую критику своих идей - главное чтобы было обоснование, даже если я его сочту спорным - обоснованная критика - всё равно полезная критика!. И я не пытаюсь необоснованно критиковать вашу разработку. Напротив - я всячески желаю Вам удачи с ней!
И сути это не меняет - нельзя ошибиться в названии переменной, если его нельзя напечатать, а можно только выбрать из списка. Нельзя ошибиться с пропущенной кавычкой, если кавычек тоже нету. Нельзя перепутать "=" или "==" в условии, если "=" тоже нету
Как я выше написал - всем есть своя цена - и всего есть плюсы и минусы. И где есть минусы - их стараются "пусть порой условно и костылями" эти минусы устранять! И таких наработок для текстовых процессоров уже уйма - так что если сравнивать кодинг лет пятьдесят назад и сейчас - это будет гигантский разрыв (даже в рамках одного текстового ЯП)! Даже за последние 10 лет IDE шагнули очень далеко вперёд. А сейчас, на волне, генеративных лингвистических алгоритмов - шагнут ещё сильнее!
(Кстати, у Вас есть имена модулей, и да - вы позволяете их выбирать из списка (как, впрочем, это позволяют и быстрые всплывающие подсказки ввода) - но решаете ли Вы проблему, когда - это имя потом меняется у модуля - везде где используется переназначаться? Для визуальных систем это, правда, плёвое дело - а текстовые процессоры пришли к решениям не так давно - рефакторинг изменения и подсчёт с отображением ссылок - но 100% надёжности это не даёт... впрочем наврядлли сейчас хоть где-то есть 100% надёжность при активном повторном использовании кода и библиотек)
А, вот, куда сейчас развиваются музыкальные редакторы (априори визуальные) - мне категорически не нравится - это навороченные визуальны монстры с красивой графической обёрткой - и скудным сложным содержимым (я не буду говорить про плагины - среди которых есть и не скудные но от того не менее простые приложения)! Вот тут действительно назрела революция! Когда-то такой был Трекерный редактор, Piano roll, драмм-машина, , затем технология VST-плагинов, затем виртуальных DSP-процессоров и мультидорожечных редакторов и наконец музыкальных приложений для платформы Kontakt (ну я не все знаковые технологии в музыко-строении перечислил). Пришла пора двигаться дальше...
Нельзя ошибиться с разыменованием NULL в рантайме, если NULL-ов тоже нету (а вместо них есть значения/объекты по умолчанию).
Вот за это всецелое УРА! Учли опыт величайшей ошибки Дейкстры! Я тоже против NULL но....
для обхода NULL придумали и целе семейство null-операторов (?. ?? ??=) и отделили nullable определения переменных/свойств от не-nullable - и это отличное подспорье - появились очень интересные и удобные техники их применения!
С NULL очень удобно и красиво решается - без NULL приводит к старом заскорузлому некрасивому (хоть и понятному) коду!
Bool? Enabled = CustomOptions["Allow"] ?? (Object as ICheckable)?.Checked;
Enabled ??= A?.B?.C?.Checked ?? true;
CustomOptions["Allow"] = Enabled;
//A?.B?.C?.Checked ??= Enabled; //Вот это, правда, в C# не прокатит
Вот попробует без поддержки NULL такое написать
Bool? Enabled = CustomOptions["Allow"] ?? (Object as ICheckable)?.Checked;
Enabled ??= A?.B?.C?.Checked ?? true;
CustomOptions["Allow"] = Enabled;
//A?.B?.C?.Checked ??= Enabled; //Вот это, правда, в C# не прокатитВот попробует без поддержки NULL такое написать
Это выглядит, как что-то связанное с настройками. С настройками я так работаю:
var ini = new Ini(); // по умолчанию загружается с именем текущей сборки. Если его нет, то создаётся пустой
bool enabled = ini["enabled", true]; // true значение по умолчанию, если его нет в .ini файле, а заодно помогает выбрать тип перегруженного индексатора
int polyphony = ini["synth"]["polyphony", 16]; // synth это название секции в .ini файле
ini["synth"]["polyphony"] = 32;
ini.Save();
// а также можно подписаться на изменение .ini файла
// извне и сразу получать уведомления об этом
ini.SectionAdded += Ini_SectionAdded;
ini.SectionRemoved += Ini_SectionRemoved;
ini.SectionChanged += Ini_SectionChanged;
ini.ValueAdded += Ini_ValueAdded;
ini.ValueChanged += Ini_ValueChanged;
ini.ValueRemoved += Ini_ValueRemoved;
ini.EnableRaisingEvents = true;
// Ну то есть поменял значение в .ini файле
// при работающей программе,
// а она их сразу и обработала.мой пример было не про опции, а про работу с null значениями - я специально старался его абстрактно написать, а "CustomOptions["Allow"] " просто привёл как понятный источник null значения, но я не указывал его физическую природу - это может быть и карта "ключ-значение" (фиг его знает откуда полученная) - или обращение какому-либо хранилищу - хоть локальному, хоть БД, или какой-либо ещё комплексный сервис - который пытает получить значение из данных, собираемых их различных источников. ИМХО - алгоритму основной логики это всё должно быть сугубо "фиолетово" - у него есть источник "CustomOptions" - вот там он будет искать значение. А если его там нет - у него есть некий процесс иного поучения этого значения, которые тоже не гарантирует успех - и только затем значение берётся из кода - для случая, когда без него дальше никак не обойтись, но по какой-то непонятной причине оно так и не было получено!
Ну а в финале - передаём (во втором случае пытаемся) значение в нужные объекты - чтобы так больше не "мучиться" и для того, что это значение ещё где-то важно должно быть - если это "где-то" существует! Не вдаваясь в подробности того - как эти все вспомогательные объекты устроены!
//A?.B?.C?.Checked ??= Enabled;
но можно написать вот так (тоже вполне коротко, красиво и читаемо):
if (A?.B?.C.Checked is not null) A.B.C.Checked = Enabled;
P.S.
Введение NULL - "Ошибка на миллиард долларов" не Дейкстры, а Хоара (впервые появился NULL в ЯП ALGOL W ) - всё время путаю
А, вот, куда сейчас развиваются музыкальные редакторы (априори визуальные) - мне категорически не нравится
Мне тоже не нравится - раздражает, что не могу скопировать ноты в буфер обмена из одной программы и вставить в другую. MusicXML конечно подходит для такого, только он слишком жирный, чтобы писать на нём с нуля.
MusicXML - он не для ручного ввода - а для автоматикой (в т.ч. кроссплатформенной) интеграции - как раз для копи/паста мог сгодиться...
Так же MusicXML априори очень гибкий и расширяемый формат. Например, в "ORANGE" помимо общих форматов музыкальных потоков WAVE и MIDI возможны и потоки в других форматах (пока сугубо теоретические - этот вопрос ещё не проработан, но заложен изначально), среди которых может быть и MusicXML; а так же запланирован (но может откажусь и буду расширять MusicXML) проприетарный открытый формат (кстати, рассматривалась база XML, JSON, Protobuf) - для более расширенного управления компонентами (как в качестве внутреннего протокола, так и для взаимодействия со сторонними компонентами). Просто у меня запланировано куда более сложное командное взаимодействие, чем набор MIDI-событий, в т.ч. с целью управления параметрами и техниками звукоизвлечения комплексных компонент (а-ля какие использует Kontakt)
Piano roll
И об этом я тоже задумывался, вот так получилось:
Собачий вальс
4 5 6
|_'_'_|_'_'_'_|_'_#_|_'_'_'_|
|_'_'_|_'_'_'_|_#_'_|_'_'_'_|
|_'_'_|_#_'_'_|_'_'_|_'_'_'_|
|_'_'_|_'_'_#_|_'_'_|_#_'_'_|
|_'_'_|_'_'_#_|_'_'_|_#_'_'_|
4 5 6
|_'_'_|_'_'_'_|_'_#_|_'_'_'_|
|_'_'_|_'_'_'_|_#_'_|_'_'_'_|
|_'_'_|_#_'_'_|_'_'_|_'_'_'_|
|_'_'_|_'_'_#_|_'_'_|_#_'_'_|
|_'_'_|_'_'_#_|_'_'_|_#_'_'_|
4 5 6
|_'_'_|_'_'_'_|_'_#_|_'_'_'_|
|_'_'_|_'_'_'_|_#_'_|_'_'_'_|
|_'_'_|_#_'_'_|_'_'_|_'_'_'_|
|_'_'_|_'_'_#_|_'_'_|_#_'_'_|
|_'_#_|_'_'_'_|_'_'_|_'_'_'_|
|_'_'_|_'_'_#_|_'_'_|_#_'_'_|
|_#_'_|_'_'_'_|_'_'_|_'_'_'_|
|_'_'_|_'_'_'O|_'_'_|O'_'_'_|
|_'_'_|_'_'_'O|_'_'_|O'_'_'_|
4 5 6
|_'_'_|_'_'_'_|_'_#_|_'_'_'_|
|_'_'_|_'_'_'_|_#_'_|_'_'_'_|
|_#_'_|_'_'_'_|_'_'_|_'_'_'_|
|_'_'_|_'_'_'O|_'_'_|O'_'_'_|
|_'_'_|_'_'_'O|_'_'_|O'_'_'_|
4 5 6
|_'_'_|_'_'_'_|_'_#_|_'_'_'_|
|_'_'_|_'_'_'_|_#_'_|_'_'_'_|
|_#_'_|_'_'_'_|_'_'_|_'_'_'_|
|_'_'_|_'_'_'O|_'_'_|O'_'_'_|
|_'_'_|_'_'_'O|_'_'_|O'_'_'_|
4 5 6
|_'_'_|_'_'_'_|_'_#_|_'_'_'_|
|_'_'_|_'_'_'_|_#_'_|_'_'_'_|
|_#_'_|_'_'_'_|_'_'_|_'_'_'_|
|_'_'_|_'_'_'O|_'_'_|O'_'_'_|
|_'_#_|_'_'_'_|_'_'_|_'_'_'_|
|_'_'_|_'_'_'O|_'_'_|O'_'_'_|
|_'_'_|_#_'_'_|_'_'_|_'_'_'_|
|_'_'_|_'_'_#_|_'_'_|_#_'_'_|
|_'_'_|_'_'_#_|_'_'_|_#_'_'_|
4 5 6
|_'_'_|_#_'_'_|_'_'_|_'_'_'_|
|_'_'_|_'_'_#_|_'_'_|_#_'_'_|
|_'_#_|_'_'_'_|_'_'_|_'_'_'_|
|_'_'_|_'_'_#_|_'_'_|_#_'_'_|
|_#_'_|_'_'_'_|_'_'_|_'_'_'_|
|_'_'_|_'_'_'O|_'_'_|O'_'_'_|
|_'_'_|_'_'_'O|_'_'_|O'_'_'_|
4 5 6
|_#_'_|_'_'_'_|_'_'_|_'_'_'_|
|_'_'_|_'_'_'O|_'_'_|O'_'_'_|
|_'_#_|_'_'_'_|_'_'_|_'_'_'_|
|_'_'_|_'_'_'O|_'_'_|O'_'_'_|
|_'_'_|_#_'_'_|_'_'_|_'_'_'_|
|_'_'_|_'_'_#_|_'_'_|_#_'_'_|
|_'_'_|_'_'_#_|_'_'_|_#_'_'_|
|_'_'_|_'_'_'_|_'_'_|_'_'_'_|
4 5 6
Не кажется Вам, что это слишком громоздко? Время Piano roll прошло...
Нет, не кажется, и пиано-ролл из музыкальных программ никуда не делся. Вы же сами чуть ранее давали ссылки на ролики с блэк-миди на пиано-ролле!
Для визуализации вариации piano roll - хорошая штука - а имею ввиду - вводить музыку с помощью него (тем боле как Вы показали в виде текстовой графики, или я Вас не правильно понял) - те же Black MIDI не создаются на piano roll - их создают сложные алгоритмы, генерирующие MIDI-события, обрабатывающие готовые музыкальные паттерны!
Вот так будет на "RANGE" в варианте ввода в проприетарном буквенно-цифровом коде (но, как уже сказал, кодированный формат ввода, в принципе, можно будет настроить любой, или использовать один из готовых вариантов):
//Первая часть партитуры
{octave:3 keys: D#600 C#600 -F#600 -A#600+-F#600 -A#600+-F#600}:repeat(2)
{octave:3 keys: D#600 C#600 -F#600 -A#600+-F#600 -D#600 -A#600+-F#600 B#600 B600+-F600 B600+-F600}
{octave:3 keys: D#600 C#600 -C#600 B600+-F600 B#600+-F600}:repeat(2)
{octave:3 keys: D#600 C#600 -C#600 B600+-F600 -D#600 B600+-F600 A#600 -A#600+-F#600 A#600+-F#600}
//Или компактнее
use (octave=3, script="keys", len=600):{
(D# C# -F# (-A#+-F#):r2):r2
D# C# -F# -A#+-F# -D# -A#+-F# B# ( B+-F):r2
(D# C# -C# ( B+-F):r2):r2
D# C# -C# B+-F -D# B+-F A# (-A#+-F#):r2}
//В более сложном примере с большим числом одинаковых партий могло бы быть ещё компактнее:
use (octave=3, script="keys", len=600):{
var n1 = {D# C# -F#}
var n2 = {D# C# -C#}
var n3 = {-A#+-F#}
var n4 = {B+-F}
(n1 n3:r2):r2
n1 n3 -D# n3 B# n3:r2
(n2 n4:r2):r2
n2 n4 -D# n4 A# n3:r2}
Надеюсь нигде не ошибся. Если съедет ровность отображение - я не виноват - изначально всё было аккуратно выровнено
P.S.
Вот серьёзно думаю заменить символ "+" для формирования аккордов на что-то другое - чтобы не путать со смещением октав, например на "*" - просто "+" уже привычен для клавиатурных аккордов "сочетаний горячих клавиш"
Я не знаю, как вы меня неправильно поняли, но этот ASCII-Piano-Roll в первую очередь был задуман, как человеко-понятный формат. Который можно взять и играть на клавишах. В котором сразу видно, где белые, а где чёрные клавиши. А если кажется, что он немного жирный - 7zip решит эту проблему.
А если текстом - то мой вариант такой:
[Собачий вальс]
@key:Gb
@octave:4
@duration:1/4
((ми ре)/2 соль {си +соль}x2)x2
(ми ре)/2 соль {си +соль} -ми
{си +соль} -ре {до фа}х2
((ми ре)/2 -ре {до фа}х2)х2
(ми ре)/2 -ре {до фа} -ми
{до фа} соль {си +соль}x2
. соль {си +соль} -ми
{си +соль} -ре {до фа}х2
. -ре {до фа} -ми
{до фа} соль {си +соль}x2Вполне себе годный вариант для текстового ввода простеньких мелодий. Но не уверен, что хорошо подойдёт для профессиональных. Просто сложные музыкальные произведения, вводимые с помощью классической нотной грамоты крайне сложны в наборе - это хорошо знают классические композиторы, например, вводящие ноты в Finale (насколько я знаю - вводить классическим путём ноты в других, более привычных современным композиторам, редактора ещё куда сложнее). Оттого и стал так популярен Piano roll - но если нужны именно классические ноты - то он не особо годится (всё равно будет много правок - тут тогда уж проще на MIDI клавиатуре наиграть и потом долго корпеть в Finale - исправляя огрехи и расставляя правильную музыкальную "пунктуацию").
Но классические ноты редко нужны современным композиторам - если надо - они сбагрят это работу музыкальным "неграм" - пусть тем в Finale корячатся... Современным "не классически " композиторам вполне хватает Piano roll (в разных вариациях + drum machine) и мультидороженный семплер + Kontakt для подключения современных программ инструментов + DSP плагины для эффектов и некоторый доп. софт для создания/обработки семплов (но этим скорее уже саунд продюсеры руководят, без них композиторы обычно берут готовые библиотеки и программы Kontakt и иногда специальные плагины для эмуляции старых синтезаторов).
Поэтому я по умолчанию и не стал делать текстовый ввод в классическом нотном стиле (хотя такой формат не проблема реализовать и подключить, хотя вру - не проблема - это как у Вас - в примитивном виде, а если нужна точная нотная грамота - это это будет жесть - но в целом решаема - но сам не планирую - разработка формата ввода свободная - если кому надо будет - пусть делает транслятор во внутренние команды, и презентёр - для визуализации и графического вывода в нужном представлении).
Я правильно понял, что у Вас аккорды через { } объединение реализованы? Тогда как решаете такую игру - когда, скажем, зажимается одна клавиша (или несколько), и в это время играются другие? При этом ещё и зажатая клавиша так же может плавно варьироваться с другой клавишей! А ещё может быть начатый аккорд - переходящий в другой аккорд, и в процессе которого берутся оба аккорда с промежуточными легато, работой педалью и т.п. В современной музыке столько интересных и сложных техник... классикам и не снилось - хотя и они тоже порой сочиняли сложные произведения!
И это мы ещё сейчас мыслим скорее в терминах клавишных инструментов а-ля класс "фортепьяно". А у музыкальных инструментов других классов (видов) куча своих особенностей построения звукосочетаний.
Поэтому я и проектирую разные гибкие форматы ввода - чтобы подстроиться под технику разных инструментов. Я тут неспец по мультиинструменталке - но вот, хотя бы про гитары, или в общем случае - про класс "щипковые струнные" инструменты - там доступно столько хитрых техник исполнения (XX век был веком расцвета струнных инструментов и техник игры на них; впрочем клавишные в лице синтезаторов не шибко отставали по вариации звучания - но там техник не так много новых появилось), которые не доступны для исполнения на клавишных инструментах. И Piano roll тут вообще бессилен - а нам предлагают даже в Kontak писать мелодию для струнных через него... фу....
Так что проблема описания сложных аккордов и прочих безымянных техник гармонизации - это очень непростой вопрос! Он даже на нотном стане непростой...
Помимо аккордов продумывать и удобный ввод таких вещи как:
Музыкальные штрихи
Мелизмы
Сложные пассажи
И некоторые другие (о которых я не знаю)
Это техники для фортепиано - а у других инструментов свои хитры техники, которые тоже как-то надо вводить!
Вопрос же не так стоит на самом деле. Вопрос стоит - насколько ваш вариант ввода нот текстом более удобен моего, потому что всегда есть альтернатива ввода графическим образом в куче редакторов. Мой любимый это overture, если что, последнее время работаю только в нём.
Вы зрите в корень - вся эта канитель по поводу Формата текстового описания (или визуальной(го)... эээ... конфигурирования) - это всё в первую очередь для удобства ввода, и удобство восприятия (чтения/анализа) человеком (впрочем у текстовых способов относительно графических есть и некоторые другие преимущества, но между собой в основном в остальном они будут равны). Да и в первую очередь, всё-таки именно удобство ввода - так как затем представление уже можно оформить в любой удобной, на данный момент для данного человека, форме!
Но это удобство - это очень обширная вещь - за ней стоит очень много нюансов. Этот как - вот раньше программы вводили машинными кодами кнопками, потом придумали перфокарты/перфоленты, потом появился ассемблер, Алгол, Си, Бейсик, Ява, Питон - формально всё это эволюция удобства ввода!
Собственно и свой ЯП "ORANGE" я задумал именно из-за того, что меня не устроило удобство ни графических систем ввода музыки, ни имеющихся ЯП кодирования (статья один и два)
И я изначально ставлю задачу так:
Возможность вводить музыка в разных текстовых форматах, в т.ч. определять свои - для максимизации удобства персонального ввода. В том числе так - чтобы музыкальный код можно было вводить непосредственно во время исполнения - в реальном временем (т.е. на "концерте") - это вообще очень сложная вещь в реализации (тут ещё со стороны IDE нужна нехилая поддержка)!
Иметь возможность гибкого повторного, в т.ч. параметрического использования музыкальных паттернов, в т.ч. через из автоматическое преобразование; в т.ч. из библиотек
Иметь возможность легко описывать специфические техники игры, присущие различным инструментам; в т.ч. техники с чётко выстроенными периодическими последовательностями, так и с нечётко
Иметь возможность вводить музыку не нотами, а математическими формулами преобразований звука (и активно применять операторы поля информатики)
Иметь возможность вводить музыку не только сухой выверенной партитурой, но с внесением музыкального окраса, натуральностью и неповторимостью звучания, как за счёт нарочитых огрехов воспроизведения, так и заложенной вариабельностью импровизации
Иметь возможность описывать сложноструктурированную вариативную музыку - которая никогда не будет сыграна идентично
Иметь возможность эффективно алгоритмически описывать наслаивания как разных звуковых голосов, так и разные эффектов, накладываемых позиционно или параллельно основной партитуры
Иметь возможность эффективно и наглядно проводить отладку музыкального кода, в т.ч. в реальном времени исполнения - это тоже достаточно сложная вещь в реализации (тут со стороны IDE нужна серьёзная поддержка)!
А насчёт альтернативы ввод в куче редакторов - так в том и дело - что реально разных вариантов раз два и обчёлся! А удобство среди них не каждый себе найдёт... я, вот, не нашёл
Я правильно понял, что у Вас аккорды через { } объединение реализованы? Тогда как решаете такую игру - когда, скажем, зажимается одна клавиша (или несколько), и в это время играются другие? При этом ещё и зажатая клавиша так же может плавно варьироваться с другой клавишей!
Очень просто решается, причём аж двумя способами - и я писал об этом в самом начале. Один - с помощью префикс-модификаторов "~" и "!", по сути и означающих "NoteOn" и "NoteOff". Другой - разбивать на голоса располагая их друг над другом:
>1: ми +ля +до*2
>2: ля*4Этого уж точно нет ни в одном из виденных мною языке. С форматом только ещё до конца определился, а в будущем ещё хочу добавить возможность для задания абсолютного положения. А мелизмы и прочие украшательства - это всё для живого исполнения, нет никакого смысла тащить их в минусовку.
Один - с помощью префикс-модификаторов "~" и "!",
Да-да - я потом вспомнил, что писали...
А я, у себя, заметил, что каое-что упустил из вида. У меня ноты играются друг за другом (кроме аккорда) - строго последовательно.... я не пока предусмотрел их полифонию. Не то чтобы совсем не предусмотрел - у меня скорее есть модель многоголосой отдельными партиями, но в формате ввода нот я не предусмотрел наслоения нот по их длительностям. Хотя.... вот нашёл - в формате для трекерной музыки я это вскользь описал в черновом варианте так
ещё один вариант записи нот из мира трекерной музыки – важное отличие: тут не задаётся напрямую длительность ноты – она звучит, пока явно не будет сброшена или не начнётся другая (ну если, нота зациклена – иначе звучит до своего конца и всё) – и тут каждая позиция имеет фиксированную длину тактов звучания (это всё настраивается), пропуск тактов «--» (обязательно отделено от нот) или «NP», заглушить ноту «00»
{ticklen:200ms tracker: D1 -- D2 -- -- D3 D4 D5 -- D6 00 NP NP D7}
Но у трекерной музыкит так же полифония задаётся отдельными голосами - на отдельных треках Так что это не то.
В общем, мне надо подумать и над форматом описания аккордов, так и над форматом полифонии нот внутри одного паттерна!
Вероятно пойду по Вашему пути - модификатор зажатия ноты и её сброса - чтобы остальные ноты не ждали пока истечёт длительность (но длительность тоже оставлю - чтобы не обязательно нужно было сбрасывать ноту).
Как-то так
D1000 С500 B500 D1000 С500 B500 - обычное чередование длительностью в условные 1000 и 500 тиков (миллисекунд в определённом значении настроенного темпа)
D_1000 С500 B500 D_1000 С500 B500 - C и B звучат на фоне звучащей ноты D - после чего она снова нажимается и звучит на фоне повтора C и B.
Но с полифонией по времени нужно учесть ещё и возможно настроенные микро паузы между звукоизвлечением - тогда всё может разъехаться во времени! И неявное снятие звучания может быть эффективнее - в едином поток синхронизации команд - возможно так тут снятие ноты D! и её повторное нажатие явное - думаю это правильно - это без легато, иначе было бы легато и фактически не было бы повторного нажатия а просто продолжение звучания - и тут тогда могут быть свои специфичные эффекты применены - не свойственные большинству физических инструментов, но доступных цифровым синтезаторам):
D* С500 B500 D! D* С500 B500
Может вместо "*" можно "~" тут надо подумать над символикой - у Вас же "*" и "/" это модификаторы длительности по мат. выражению справа? Насчёт "*" у меня вертится и другой вариант интерпретации - обозначения бита - быстрого удара в т.ч. по клавише или струне - с моментальным приглушением (без сустейна). А для "~" тональный переход от ноты к ноте "C~+C" (октава) - а-ля глисcандо или некоторые аналогичные техники в других инструментах. Но, в общем, надо подумать - это специфик - можно и через модификатор сделать "(C +C):gliss".
С аккордами тоже думаю стоит отказать от синтаксиса A+D - т.е. плюс ещё это увеличение октавы (сейчас с эти нет технических противоречий т.к. A+D это не то же самое что A +D и не A++D (первый плюс - это связующая аккорда - второй - увеличение октавы) - но всё это не наглядно и плохо воспринимается - прям С++ какой-то выходит - а я его терпеть не могу!
Да - брал пример с сочетания горячих клавиш Ctrl+Shift+A - но... во-первых тут нет относительных сдвигов, а во вторых - тут нет порядка нажатия и в третьих не требуется одновременность! Так что - это неудачный ориентир
У Вас логично аккорд обозначается {ля ре} фигурными скобками. У меня фигурные скобки - это блок кода - и я не хотел бы на них вешать какой-то иной функционал описания логики.
Но есть ещё и ( ) [ ] < > скобки. У меня обычные ( ) скобки тоже задействованы - это группа нот (или чего-то ещё), на которую нужно применить одинаковый модификатор.
Во-первых эту логику можно перевесить на фигурные { } скобки.
Во-вторых аккорд - это тоже, по сути, модификатор "(А D):accord" Да, и можно пойти на хитрость - если фигурные скобки без модификатора - то по умолчанию подразумевается аккорд "(A D)" а так "(A D):r2" - это уже повтор "A D A D" а так (A D):acc:r2 - это повтор аккорда "A+D A+D"
В третьих как раз для модификаторов можно оставить фигурные { } скобки - но в математических выражениях (где тоже могут быть модификаторы) они явно будут не к месту вместо ( )
В-четвёртых - есть квадратные [ ] скобки для аккорда - они и так уже определяют список!
В-пятых, аккорд можно ещё и через символ объединения обозначить - но в каких-то границах-скобках (A|D)
Главное чтобы не начали тут накручивать каких-либо сложно интерпретируемых выражений:
((A | D) | (C | F))
((A A A) | (F F F C))
A | D# | B | C&
Другой - разбивать на голоса располагая их друг над другом
Само собой у меня это тоже есть. И не только отдельными треками
Простейший способ
sound("имя голосас1") { ноты и инструкции голоса 1 }
sound("имя голоса 2") { ноты и инструкции голоса 2 }
Команда sound, в отличии от sample не блокирует текущий поток трека - она асинхронна (по сути это сахар для "async sample"). Само собой есть и спец. инструкции для синхронизации как signal и waitsignal (и некоторые другие, например mark - что и сигнал и ожидание) - это нужно для сложных алгоритмов
Но можно и просто запустить блок инструкций асинхронно
run { партия 1 }
run { партия 2 }
и даже потом синхронизировать завершение
var p1 = run { партия 1 }
var p2 = run { партия 2 }
wait (p1, p2)
А ещё можно так
var p1 = { партия 1 }
var p2 = { партия 2 }
run (p1, p2):scale(fit)
Тут автоматически масштабируется исполнение двух партий так - чтобы они начались и закончились одновременно (mark внутри - позволит расставить опорные точки; одну из партий можно назначить ведущей)
Ну и, думаю над таким форматом многоголосной полифонии (синтаксис пока не зафиксирован):
{
(A400 A200 A200)
| (-D800)
| (F200 +F200 -F200 ++FF200)
}
Да-да - то что выше написал как недопустимый для аккордов - просто тут это можно интерпретировать не как аккорды - как параллельное исполнение (по сути динамически текущие сочетания одновременно нажатых клавиш)
Преимущество такого подхода в том - что это единый бок инструкций { } и к нему можно применить все операции и модификаторы как единому блоку - но он будет уже с полифонией в 3 голоса!
Есть ещё хитрый оператор "by" - который так же позволяет запустить код в блоке справа от него параллельно с кодом в блоке слева от него - но это зависимое распараллеливание - контекст блока справа будет тот же - что и у блока слева - это удобно когда на ноты (или одиночный / группу семплов слева) нужно наложить распределённые во времени эффекты - расположенные в блоке справа! Впрочем у меня задуманы и более хитры техники параллельного вызова специально оформленных функций эффектов - которые могут применяться в поточном режиме при рендеринге выходного результата, с динамически меняющимися параметрами выполнения (что-то наподобие асинхронных функций генераторов перечисляемых объектов в C# - только на выходе динамическая числовая величина, а параметры выполнения так же зависят от не статичных значений переменных)!
А мелизмы и прочие украшательства - это всё для живого исполнения, нет никакого смысла тащить их в минусовку.
Что для вас украшательства - для меня важные атрибуты исполнения.
Как уже написал ранее - одно дело - просто оформить ноты, которое далее в своей манере будет исполнять человек (кстати не обязательно - с вариативной интонацией может, в принципе, сыграть и робот). Другое дело - это сразу описывать произведение - готовое к немедленно автоматическому рендерингу в поток звука - для прослушивания / записи / исполнении в реальном времени на концерте (тут вообще нужно очень быстро и аккуратно всё вводить) - т.е. тут робот играет сразу - и имеет смысл задать все музыкальные нюансы исполнения какие потребуется!
Ну и не только мелизмы и штрихи сложно вводить! Порой сложные пассажи - это часть музыкального произведения! И я хочу стремиться упростить их ввод!
готов принять любую критику своих идей
Я не могу критиковать ваши идеи, потому что мы в разные стороны идём. Вы идёте в сторону Csound, а я развиваю идеи NI Reaktor`а, чтобы получить то, что мне в нём не хватало, и что авторы не сделают никогда просто потому, что это коммерческий продукт.
Все-таки с читаемостью проблемы: по классике у нас есть "золотой путь" - вертикальная прямая наилучшего случая, находится слева или по центру. По бокам - ответвления обработки ошибок. Я пробовал LabView, с ростом сложности получается каша и теряется понимание, как оно вообще должно работать в идеальном случае.
Если же говорить о далёком будущем (прогнозируя на десятки лет вперёд), то я твёрдо уверен, что будущее именно за графическими средствами разработки. Графическое представление алгоритмов имеет огромное количество преимуществ над текстовым. Однако в данный момент LabVIEW чуть опережает время, и язык G пока не может стать языком "общего назначения". Причин тут много - наличие огромного количества развитых текстовых языков и инфоцыганщины, низкое качество кодогенерации, отсутствие стандарта, лабораторная и промышленная ориентации, высокая стоимость средств разработки, огромный, даже по нынешним меркам размер Run-Time, и т.д. Первым шагом графический язык должен стать языком общепринятым, с устоявшимся стандартом, и лишь потом, на ее базе может появиться операционная система, практически полностью написанная на этом языке. Ну и если говорить о системе с полностью открытыми кодами, то и средства разработки должны быть такими же - то есть сначала должен появиться в широких массах типа GitHub, компилятор языка G с открытыми кодами (вообще говоря он сам по себе должен быть полностью написан на G и уметь компилировать самого себя), и лишь, почему бы и нет, а да, далее - операционная система на принципиально новом качестве мышления визуальных кодеров нового поколения.
Обоснуете? Выше я тут уже приводил аргументы против графических ЯП! И привёл лишь капельку аргументов за! Некоторые из комментирующих так же привели капельку аргументов за и против. Но в целом - я тут пока не вижу значимых аргументов за графическое программирование, тем более, если говорить о далёком будущем - что там такого должно быть, чтобы визуальная разработка заметно перевесила иные способы (кстати, не обязательно текстовые - если уже говорите о далёком будущем, хотя тогда стоит хорошо подумать - какие ещё могут быть альтернативы)? А не просто визуальные системы станут лишь подспорьем для других способов
Замечу, что и визуальная разработка тоже может иметь много разных вариаций модели представления. Даже (чаще всего в комментариях рассматриваемые) диаграммы - могут иметь совершенно разные форматы. Вы за какой?
Но в целом - я тут пока не вижу значимых аргументов за графическое программирование, тем более, если говорить о далёком будущем - что там такого должно быть, чтобы визуальная разработка заметно перевесила иные способы
Так Вы и не увидите эти самые аргументы, т.к. основная, собравшаяся здесь аудитория прямо или косвенно завязана на скрипт языки. Люди не могут, да и не хотят повернуть здесь в теме свое мышление вспять, т.к. G среда для них инородная от инакомыслия. Хотите получить много аргументов за, поднимите свой диалог в G сообществах.
Я Вам ранее привел свой личный опыт работы с LW, который странным образом на Вас не оказал никакого влияния и у меня к Вам встречный вопрос - на сколько активно в анализе ответов на свой пост Вы злоупотребляете обращение к GPT? Без обид, но уж очень стилистика смахивает на это.
Как и Вы я здесь в других публикациях хотел услышать не предвзятый интерес к тому чем занимаюсь, в результате моя карма по в.у. причинам опустилась минусаторами ниже плинтуса.
Не ищите черную кошку в подвале без света, которой там нет.)
Так Вы и не увидите эти самые аргументы, т.к. основная, собравшаяся здесь аудитория прямо или косвенно завязана на скрипт языки. Л
Дело не в этом - дело в том, что нечего видеть - сторонники визуального программирования вообще не приводят таких аргументов - либо делают это так не умело, что зашоренный вгзляд "текстовых" разработчиков их в упор не видит.
Люди не могут, да и не хотят повернуть здесь в теме свое мышление вспять, т.к. G среда для них инородная от инакомыслия
Если Вы посмотрите мои комментарии - то заметите, что мои взгляды очень широкие - и я пытался даже отчасти защищать визуальное программирование - и приводить свои аргументы о то, как эффективно его можно использовать!
Хотите получить много аргументов за, поднимите свой диалог в G сообществах.
Почти уверен, что конструктивного диалога не получится - изгои представители узких проф. сообществ обычно очень критично настроены против "неверных" вторженцев! Просто выльют ушат грязи и пошлют куда подальше!
Я Вам ранее привел свой личный опыт работы с LW
Замечу - что ни разу не критиковал LabView - если Вам удобно, и нет того, кто смог бы Вам показать лучшую альтернативу - пользуйтесь (кому нравится photoshop, кому-то и paint сгодится - и я не уточняю кто здесь кто) - и получайте удовольствие! Но Вы же постулируете нам всем такое будущее - но не обоснуете это никак...
Вам встречный вопрос - на сколько активно в анализе ответов на свой пост Вы злоупотребляете обращение к GPT?
Вообще не понял Ваш вопрос
Нейролингвистические генеративные системы я использую только для кодирования программного кода!
Честно - пробовал картинки рисовать - ничего толкового не вышло - но, наверное, я просто "не умею их готовить" - это чисто мой косяк. Предвкушаю Ваш ответ - что и визуальное программирование я просто "не умею готовить" - и будете правы! Но всё же, я пытаюсь анализировать ситуацию так глубоко, насколько хватает моего опыта - привожу обоснованные аргументы, и пока не вижу обоснованных контр аргументов!
Вам встречный вопрос - на сколько активно в анализе ответов на свой пост Вы злоупотребляете обращение к GPT? Б
Я Вас не минусовал. Ну а чтобы не получать минуса от других - попробуйте всё-таки точнее излагать мысли и конкретнее отвечать на вопросы - того глядишь и карма поправится! Хотя... на хабре чаще любят необоснованно минусовать - чем плюсовать - с этим пока приходится мириться - особенно если Вы не такой как там амёбная масса - которая ставит минуса на хабре...
Но в целом - я тут пока не вижу значимых аргументов за графическое программирование, тем более, если говорить о далёком будущем - что там такого должно быть, чтобы визуальная разработка заметно перевесила иные способы
Для наглядности представлю одну и ту же процедуру текстовом исполнении и в G коде, после чего хотелось бы услышать Ваш коммент о том, какими навыками и знаниями должны обладать оба кодера, порог входа в обе IDE, прочие аргументы:
Слева находится программа Arduino для мигания светодиода с задержкой в 1 секунду, а справа его графическая копия, сделанная с помощью программы LabVIEW. Каждый раз, когда вы нажимаете кнопку «ОК», логический светодиод будет мигать с задержкой в 1 секунду.
Ну в довесок подобное еще на Python
В случае текста:
Знать язык программирования
Уметь читать текст
Уметь набирать текст на клавиатуре
Уметь мыслить связанными терминами
Знать стандартную библиотеку доступных типов и методов платформы
В случае изображения:
Знать символику графических представлений
Знать условные графические обозначения и паттерны
Знать правила связывания блоков и общую логику их взаимодействий
Уметь читать текст
Уметь набирать текст на клавиатуре и/или пользовать визуальными контролами для выбора нужных значений
Уметь мылить визуальными графическими представлениями как связзной структурой
Уметь хотя бы в общих чертах визуализировать схемы мышью
Быть хотя бы знакомым с графовыми и сетевыми структурами
Владеть библиотекой компонент как в текстовом так и в визуальном представлении
Владеть инструментарием платформы для визуализации и выбора компонент
Может что-то ещё - сходу сложно всё консолидировать!
Графическая схема на почти на два порядка сложнее в восприятии и начертании чем текст слева (но уточню - что люди разные - и кому-то может оказаться наоборот - но это, скорее исключение)!
Текст внизу сложный - но он тоже проще чем графическая схема. Но его сложность обусловлена лишь особенностями выбора библиотек и синтаксического сахара конкретного ЯП - текстовые ЯП позволяют писать куда проще. Ещё не известно сколько настроек скрыто за графическими элементами внутри их свойств!
На моём ЯП 5-го поколения код был бы такой
var diod : //Считаем что у нас нет готового типа для компоненты Diod в библиотеке. Но вообще идея 5-го поколения ЯП в накоплении единых паттернов и шаблонов для адаптивного применения - так что если есть какой-то общедоступный диод - то в библиотеке с вероятностью блиpкой к 100% будет уже готовый тип для работы с ним (как в Arduino) - останется только в поkу автоматическом виде его адаптировать в контекст, и скорректировать контракт API
{
val какие-то свойства диода
def Init -> { какая-то установка свойств - возьмёте из питона}
def On-> { какие-то аппаратные инструкции - возьмёте из питона}
def Off-> { какие-то аппаратные инструкции - возьмёте из питона}
}
ButtonOk.OnClick <- Async (1..3) -> Block{ diod.On; Delay(1000); diod.Off; Delay (1000) }Хотел ответить, но успел схватить себя за руку, т.к. ничего путного из разговора не получится, когда в теме присутствует подавляющее большинство скрипт кодеров сидят на заборе с попкорном в ожидании - фас его). Я выше уже писал о таких потасовках. Если начинаешь демонстрировать примеры, оппонент в лучшем случае скажет - прикольненько, но оно мне не надо и я не знаю где это применить, в худшем - появится несколько анонимных минусаторов, которые ходят за мной по пятам, но я их знаю, и начнут тупо без аргументов забивать карму. Так что время нас рассудит.
Если в статье про визуальное программирование нет упоминания:
- Кузнецов Побиск Георгиевич диаграмма сетевого планирования,
- Шалыто Анатолий Абрамович автоматное программирование граф переходов увидел и понял,
- Паронджанов Владимир Даниэлович язык ДРАКОН.
То упомяну.
Насколько нам нужно визуальное программирование?