Как описал выше - блокировка неизвестных протоколов тема не простая! Так как тут нужно иметь большую базу известных протоколов, иметь на их анализ достаточное количестве ресурсов. И быстро реагировать на новые неизвестные протоколы с "легальным трафиком" - коих появляется каждый годы сотни - и если на это не реагировать - последствия для взаимодействия с сетью Интернет будет ненамного лучше - полной изоляции!
А то, что мимикрируют под известные протоколы уже сейчас - с этим спорить не буду!
Да, у Гугла сейчас тоже полно своих перегибов... пока нет ни одной свободной от оков мракобесия и адекватной сети публичного распространения информации. Наиболее близкая к этому - скорее Telegram
Потеря десяток и сотен миллионов евро для экономики почти любой страны с населением в штуках больше "единиц бумажек" в данной сумме - это не серьёзная проблема вообще!
Раз исключили конкретный браузер (а не наоборот - прописали доступные конкретные браузеры) - то, скорее всего, это специальная "закладка" - чистый протест! Никаких технических фишек тут нет!
Есть, конечно, такая идея на будущее - по обходу блокировки по протоколу - это динамически настраиваемые протоколы - когда для каждого клиента можно условно создать свой протокол. И тут AI технологии могут сыграть очень важную роль!
Но - в отвертку может прийти запрет всего неизвестного - всех не известных протоколов! Да - будет выходить новый софт, не связанный с VPN - но его протоколы могут анализироваться и разрешаться по необходимости! Да - задержка будет большая - но такая стратегия тоже возможна - и тут, для ускорения анализа, как раз AI технологии тоже будут очень полезны! Ну и да - мощности для анализа трафика по миллионам протоколов потребуются запредельные - а скорости трафика снизятся конкретно! Тут уже, скорее, всем, кому это будет важно - реально будет проще транслировать себя целиком туда - где нет этих блокировок - ибо для них перспективы жизни в таком обществе вряд ли вообще будут приемлемы (не из-за блокировок даже - а из-за общей тенденции - ради которой и устраиваются эти блокировки)!
В ответку на ответку - блокируемы трафик можно пробовать маскировать под неблокируемый - т.е. под разрешённые протоколы - сейчас есть много таких, мне первым делом приходят на ум игры (вспоминаю сериал Адаптация) - где под видом легального трафика можно пропихивать блокируемый! Конечно скорости резко упадут... и о рантайме навряд ли можно будет говорить!
Но и тут, могут найтись, способы блокировки.... как и способы дальнейшего обхода! Но тут надо понимать - кому нужны будут такие сложности преодоления - обычным людям, скорее уже будет куда проще себя перенести (ну если границы так же не начнут блокировать - что вполне себе возможно на таком уровне социального безумия)! так что, дальнейшее сопротивление блокировкам - это уже уровень шпионажа и криминала! Больше никому так напрягаться не захочется....
Проблема в том, что VPN-трафик можно распознавать и блокировать. Это не просто и очень ресурсоёмко - но это не значит, что не решается!
В обще-то RDP трафик тоже можно распознавать и блокировать - но это совсем дргая тема - а пока РКН у нас с VPN борется - и руки (и мощности) до RDP - не скоро дойдут - власть скорее сменится... хотя там ещё тоже не ясно - чего ждать!
Так что готовьтесь лучше к худшему - покупайте чемоданы - пока их ещё не блокируют их приобретение!
Знать стандартную библиотеку доступных типов и методов платформы
В случае изображения:
Знать символику графических представлений
Знать условные графические обозначения и паттерны
Знать правила связывания блоков и общую логику их взаимодействий
Уметь читать текст
Уметь набирать текст на клавиатуре и/или пользовать визуальными контролами для выбора нужных значений
Уметь мылить визуальными графическими представлениями как связзной структурой
Уметь хотя бы в общих чертах визуализировать схемы мышью
Быть хотя бы знакомым с графовыми и сетевыми структурами
Владеть библиотекой компонент как в текстовом так и в визуальном представлении
Владеть инструментарием платформы для визуализации и выбора компонент
Может что-то ещё - сходу сложно всё консолидировать!
Графическая схема на почти на два порядка сложнее в восприятии и начертании чем текст слева (но уточню - что люди разные - и кому-то может оказаться наоборот - но это, скорее исключение)!
Текст внизу сложный - но он тоже проще чем графическая схема. Но его сложность обусловлена лишь особенностями выбора библиотек и синтаксического сахара конкретного ЯП - текстовые ЯП позволяют писать куда проще. Ещё не известно сколько настроек скрыто за графическими элементами внутри их свойств!
На моём ЯП 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) }
А я, у себя, заметил, что каое-что упустил из вида. У меня ноты играются друг за другом (кроме аккорда) - строго последовательно.... я не пока предусмотрел их полифонию. Не то чтобы совсем не предусмотрел - у меня скорее есть модель многоголосой отдельными партиями, но в формате ввода нот я не предусмотрел наслоения нот по их длительностям. Хотя.... вот нашёл - в формате для трекерной музыки я это вскользь описал в черновом варианте так
ещё один вариант записи нот из мира трекерной музыки – важное отличие: тут не задаётся напрямую длительность ноты – она звучит, пока явно не будет сброшена или не начнётся другая (ну если, нота зациклена – иначе звучит до своего конца и всё) – и тут каждая позиция имеет фиксированную длину тактов звучания (это всё настраивается), пропуск тактов «--» (обязательно отделено от нот) или «NP», заглушить ноту «00»
Но у трекерной музыкит так же полифония задаётся отдельными голосами - на отдельных треках Так что это не то.
В общем, мне надо подумать и над форматом описания аккордов, так и над форматом полифонии нот внутри одного паттерна!
Вероятно пойду по Вашему пути - модификатор зажатия ноты и её сброса - чтобы остальные ноты не ждали пока истечёт длительность (но длительность тоже оставлю - чтобы не обязательно нужно было сбрасывать ноту).
Как-то так
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 внутри - позволит расставить опорные точки; одну из партий можно назначить ведущей)
Ну и, думаю над таким форматом многоголосной полифонии (синтаксис пока не зафиксирован):
Да-да - то что выше написал как недопустимый для аккордов - просто тут это можно интерпретировать не как аккорды - как параллельное исполнение (по сути динамически текущие сочетания одновременно нажатых клавиш)
Преимущество такого подхода в том - что это единый бок инструкций { } и к нему можно применить все операции и модификаторы как единому блоку - но он будет уже с полифонией в 3 голоса!
Есть ещё хитрый оператор "by" - который так же позволяет запустить код в блоке справа от него параллельно с кодом в блоке слева от него - но это зависимое распараллеливание - контекст блока справа будет тот же - что и у блока слева - это удобно когда на ноты (или одиночный / группу семплов слева) нужно наложить распределённые во времени эффекты - расположенные в блоке справа! Впрочем у меня задуманы и более хитры техники параллельного вызова специально оформленных функций эффектов - которые могут применяться в поточном режиме при рендеринге выходного результата, с динамически меняющимися параметрами выполнения (что-то наподобие асинхронных функций генераторов перечисляемых объектов в C# - только на выходе динамическая числовая величина, а параметры выполнения так же зависят от не статичных значений переменных)!
А мелизмы и прочие украшательства - это всё для живого исполнения, нет никакого смысла тащить их в минусовку.
Что для вас украшательства - для меня важные атрибуты исполнения.
Как уже написал ранее - одно дело - просто оформить ноты, которое далее в своей манере будет исполнять человек (кстати не обязательно - с вариативной интонацией может, в принципе, сыграть и робот). Другое дело - это сразу описывать произведение - готовое к немедленно автоматическому рендерингу в поток звука - для прослушивания / записи / исполнении в реальном времени на концерте (тут вообще нужно очень быстро и аккуратно всё вводить) - т.е. тут робот играет сразу - и имеет смысл задать все музыкальные нюансы исполнения какие потребуется!
Ну и не только мелизмы и штрихи сложно вводить! Порой сложные пассажи - это часть музыкального произведения! И я хочу стремиться упростить их ввод!
Вы зрите в корень - вся эта канитель по поводу Формата текстового описания (или визуальной(го)... эээ... конфигурирования) - это всё в первую очередь для удобства ввода, и удобство восприятия (чтения/анализа) человеком (впрочем у текстовых способов относительно графических есть и некоторые другие преимущества, но между собой в основном в остальном они будут равны). Да и в первую очередь, всё-таки именно удобство ввода - так как затем представление уже можно оформить в любой удобной, на данный момент для данного человека, форме!
Но это удобство - это очень обширная вещь - за ней стоит очень много нюансов. Этот как - вот раньше программы вводили машинными кодами кнопками, потом придумали перфокарты/перфоленты, потом появился ассемблер, Алгол, Си, Бейсик, Ява, Питон - формально всё это эволюция удобства ввода!
Собственно и свой ЯП "ORANGE" я задумал именно из-за того, что меня не устроило удобство ни графических систем ввода музыки, ни имеющихся ЯП кодирования (статья один и два)
И я изначально ставлю задачу так:
Возможность вводить музыка в разных текстовых форматах, в т.ч. определять свои - для максимизации удобства персонального ввода. В том числе так - чтобы музыкальный код можно было вводить непосредственно во время исполнения - в реальном временем (т.е. на "концерте") - это вообще очень сложная вещь в реализации (тут ещё со стороны IDE нужна нехилая поддержка)!
Иметь возможность гибкого повторного, в т.ч. параметрического использования музыкальных паттернов, в т.ч. через из автоматическое преобразование; в т.ч. из библиотек
Иметь возможность легко описывать специфические техники игры, присущие различным инструментам; в т.ч. техники с чётко выстроенными периодическими последовательностями, так и с нечётко
Иметь возможность вводить музыку не нотами, а математическими формулами преобразований звука (и активно применять операторы поля информатики)
Иметь возможность вводить музыку не только сухой выверенной партитурой, но с внесением музыкального окраса, натуральностью и неповторимостью звучания, как за счёт нарочитых огрехов воспроизведения, так и заложенной вариабельностью импровизации
Иметь возможность описывать сложноструктурированную вариативную музыку - которая никогда не будет сыграна идентично
Иметь возможность эффективно алгоритмически описывать наслаивания как разных звуковых голосов, так и разные эффектов, накладываемых позиционно или параллельно основной партитуры
Иметь возможность эффективно и наглядно проводить отладку музыкального кода, в т.ч. в реальном времени исполнения - это тоже достаточно сложная вещь в реализации (тут со стороны IDE нужна серьёзная поддержка)!
А насчёт альтернативы ввод в куче редакторов - так в том и дело - что реально разных вариантов раз два и обчёлся! А удобство среди них не каждый себе найдёт... я, вот, не нашёл
Так Вы и не увидите эти самые аргументы, т.к. основная, собравшаяся здесь аудитория прямо или косвенно завязана на скрипт языки. Л
Дело не в этом - дело в том, что нечего видеть - сторонники визуального программирования вообще не приводят таких аргументов - либо делают это так не умело, что зашоренный вгзляд "текстовых" разработчиков их в упор не видит.
Люди не могут, да и не хотят повернуть здесь в теме свое мышление вспять, т.к. G среда для них инородная от инакомыслия
Если Вы посмотрите мои комментарии - то заметите, что мои взгляды очень широкие - и я пытался даже отчасти защищать визуальное программирование - и приводить свои аргументы о то, как эффективно его можно использовать!
Хотите получить много аргументов за, поднимите свой диалог в G сообществах.
Почти уверен, что конструктивного диалога не получится - изгои представители узких проф. сообществ обычно очень критично настроены против "неверных" вторженцев! Просто выльют ушат грязи и пошлют куда подальше!
Я Вам ранее привел свой личный опыт работы с LW
Замечу - что ни разу не критиковал LabView - если Вам удобно, и нет того, кто смог бы Вам показать лучшую альтернативу - пользуйтесь (кому нравится photoshop, кому-то и paint сгодится - и я не уточняю кто здесь кто) - и получайте удовольствие! Но Вы же постулируете нам всем такое будущее - но не обоснуете это никак...
Вам встречный вопрос - на сколько активно в анализе ответов на свой пост Вы злоупотребляете обращение к GPT?
Вообще не понял Ваш вопрос
Нейролингвистические генеративные системы я использую только для кодирования программного кода!
Честно - пробовал картинки рисовать - ничего толкового не вышло - но, наверное, я просто "не умею их готовить" - это чисто мой косяк. Предвкушаю Ваш ответ - что и визуальное программирование я просто "не умею готовить" - и будете правы! Но всё же, я пытаюсь анализировать ситуацию так глубоко, насколько хватает моего опыта - привожу обоснованные аргументы, и пока не вижу обоснованных контр аргументов!
Вам встречный вопрос - на сколько активно в анализе ответов на свой пост Вы злоупотребляете обращение к GPT? Б
Я Вас не минусовал. Ну а чтобы не получать минуса от других - попробуйте всё-таки точнее излагать мысли и конкретнее отвечать на вопросы - того глядишь и карма поправится! Хотя... на хабре чаще любят необоснованно минусовать - чем плюсовать - с этим пока приходится мириться - особенно если Вы не такой как там амёбная масса - которая ставит минуса на хабре...
К сожалению - все Ваши ответы - выстрел в воздух... ибо говорил я совсем о другом, и не смотрел пристально в стороны LabView - а мысли более обобщённо!
Говоря о библиотеках - я говорил и узкоспециализированных (но, впрочем и об обобщённых - но при условии, когда архитектуре выстраивается от частного конкретного - к общему абстрактному, но очень гибкому, чтобы можно было в сановном логику выстраивать через общие абстрактное - чтобы применять обобщённые библиотеки) прикладных библиотеках для торгового робота (или какой ещё специализированной прикладной системы)! Ну и они должны быть хорошо задокументированы (в том числе, хотя бы, самодокументированы).
Говоря о кодогенгераторах - я имел в виду глубину перехода от абстракций - к конкретным инструкциям! Чем круче база статических анализаторов и кодогенераторов - тем менее системный алгоритм надо писать - удаляясь от внутренней технической части робота или иной прикладной системы, и тем больше модно сосредоточиться на общей прикладной логике и процессах взаимодействий сложных узлов и людей!
Говоря об отладчиках - тут я не понял Ваши мысли. Может пояснить? Я говорил - что прикладной код должен сейчас, и тем более в будущем, иметь высокую способность к глубокой и высокоуровневой отладке - чтобы экономить время разработчика и повышать его информируемость! И тут я уже говорил - что у визуального представления есть свои некоторые полезные фишки для этого - но я подчеркну, что ради них нет смысла именно программировать визуально - достаточно получить построенную визуальную модуль алгоритма по иному формату описания, каким бы он ни был!
Говоря о тулзах - сейчас в IDE и текстовых процессора саммые продвинутые суппорт тулзы - по вводу анализу, рефакторингу, версионирования, прогнозируемого автоввода, автоисправления, шаблонизироания и динамического применения паттерном для текста и т.д. и т.п. визуальным средам до этого ещё расти и расти... это просто пропасть! Но... это не значит что визуальные системы не смогут это всё наверстать (но это титанический будет труд). Другое дело что на это всё уйдут не годы... минимум десятилетия а скорее всего столетия - за это время и текстовые процессоры, и, уже тем более, какие-то иные средства ввода и манипулирования информацией - дадут ещё больший скачок вперёд - т.к. пока они на пике прогресса - и большая часть людей сосредоточит свои умы именно на их развитии - и если случится устойчивый перелом - то на то, чтобы он набрал кульминационный темп - потребуется уйма времени - ибо ломка мышления и парадигм будет страшная!
Вполне себе годный вариант для текстового ввода простеньких мелодий. Но не уверен, что хорошо подойдёт для профессиональных. Просто сложные музыкальные произведения, вводимые с помощью классической нотной грамоты крайне сложны в наборе - это хорошо знают классические композиторы, например, вводящие ноты в Finale (насколько я знаю - вводить классическим путём ноты в других, более привычных современным композиторам, редактора ещё куда сложнее). Оттого и стал так популярен Piano roll - но если нужны именно классические ноты - то он не особо годится (всё равно будет много правок - тут тогда уж проще на MIDI клавиатуре наиграть и потом долго корпеть в Finale - исправляя огрехи и расставляя правильную музыкальную "пунктуацию").
Но классические ноты редко нужны современным композиторам - если надо - они сбагрят это работу музыкальным "неграм" - пусть тем в Finale корячатся... Современным "не классически " композиторам вполне хватает Piano roll (в разных вариациях + drum machine) и мультидороженный семплер + Kontakt для подключения современных программ инструментов + DSP плагины для эффектов и некоторый доп. софт для создания/обработки семплов (но этим скорее уже саунд продюсеры руководят, без них композиторы обычно берут готовые библиотеки и программы Kontakt и иногда специальные плагины для эмуляции старых синтезаторов).
Поэтому я по умолчанию и не стал делать текстовый ввод в классическом нотном стиле (хотя такой формат не проблема реализовать и подключить, хотя вру - не проблема - это как у Вас - в примитивном виде, а если нужна точная нотная грамота - это это будет жесть - но в целом решаема - но сам не планирую - разработка формата ввода свободная - если кому надо будет - пусть делает транслятор во внутренние команды, и презентёр - для визуализации и графического вывода в нужном представлении).
Я правильно понял, что у Вас аккорды через { } объединение реализованы? Тогда как решаете такую игру - когда, скажем, зажимается одна клавиша (или несколько), и в это время играются другие? При этом ещё и зажатая клавиша так же может плавно варьироваться с другой клавишей! А ещё может быть начатый аккорд - переходящий в другой аккорд, и в процессе которого берутся оба аккорда с промежуточными легато, работой педалью и т.п. В современной музыке столько интересных и сложных техник... классикам и не снилось - хотя и они тоже порой сочиняли сложные произведения!
И это мы ещё сейчас мыслим скорее в терминах клавишных инструментов а-ля класс "фортепьяно". А у музыкальных инструментов других классов (видов) куча своих особенностей построения звукосочетаний.
Поэтому я и проектирую разные гибкие форматы ввода - чтобы подстроиться под технику разных инструментов. Я тут неспец по мультиинструменталке - но вот, хотя бы про гитары, или в общем случае - про класс "щипковые струнные" инструменты - там доступно столько хитрых техник исполнения (XX век был веком расцвета струнных инструментов и техник игры на них; впрочем клавишные в лице синтезаторов не шибко отставали по вариации звучания - но там техник не так много новых появилось), которые не доступны для исполнения на клавишных инструментах. И Piano roll тут вообще бессилен - а нам предлагают даже в Kontak писать мелодию для струнных через него... фу....
Так что проблема описания сложных аккордов и прочих безымянных техник гармонизации - это очень непростой вопрос! Он даже на нотном стане непростой...
Помимо аккордов продумывать и удобный ввод таких вещи как:
Музыкальные штрихи
Мелизмы
Сложные пассажи
И некоторые другие (о которых я не знаю)
Это техники для фортепиано - а у других инструментов свои хитры техники, которые тоже как-то надо вводить!
Обоснуете? Выше я тут уже приводил аргументы против графических ЯП! И привёл лишь капельку аргументов за! Некоторые из комментирующих так же привели капельку аргументов за и против. Но в целом - я тут пока не вижу значимых аргументов за графическое программирование, тем более, если говорить о далёком будущем - что там такого должно быть, чтобы визуальная разработка заметно перевесила иные способы (кстати, не обязательно текстовые - если уже говорите о далёком будущем, хотя тогда стоит хорошо подумать - какие ещё могут быть альтернативы)? А не просто визуальные системы станут лишь подспорьем для других способов
Замечу, что и визуальная разработка тоже может иметь много разных вариаций модели представления. Даже (чаще всего в комментариях рассматриваемые) диаграммы - могут иметь совершенно разные форматы. Вы за какой?
Для визуализации вариации piano roll - хорошая штука - а имею ввиду - вводить музыку с помощью него (тем боле как Вы показали в виде текстовой графики, или я Вас не правильно понял) - те же Black MIDI не создаются на piano roll - их создают сложные алгоритмы, генерирующие MIDI-события, обрабатывающие готовые музыкальные паттерны!
Вот так будет на "RANGE" в варианте ввода в проприетарном буквенно-цифровом коде (но, как уже сказал, кодированный формат ввода, в принципе, можно будет настроить любой, или использовать один из готовых вариантов):
//В более сложном примере с большим числом одинаковых партий могло бы быть ещё компактнее: 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.
Вот серьёзно думаю заменить символ "+" для формирования аккордов на что-то другое - чтобы не путать со смещением октав, например на "*" - просто "+" уже привычен для клавиатурных аккордов "сочетаний горячих клавиш"
Протесты бывают очень странные - но от того не менее протестующие! Цель ведь одна - привлечение внимания!
Как описал выше - блокировка неизвестных протоколов тема не простая! Так как тут нужно иметь большую базу известных протоколов, иметь на их анализ достаточное количестве ресурсов. И быстро реагировать на новые неизвестные протоколы с "легальным трафиком" - коих появляется каждый годы сотни - и если на это не реагировать - последствия для взаимодействия с сетью Интернет будет ненамного лучше - полной изоляции!
А то, что мимикрируют под известные протоколы уже сейчас - с этим спорить не буду!
Да, у Гугла сейчас тоже полно своих перегибов... пока нет ни одной свободной от оков мракобесия и адекватной сети публичного распространения информации. Наиболее близкая к этому - скорее Telegram
Потеря десяток и сотен миллионов евро для экономики почти любой страны с населением в штуках больше "единиц бумажек" в данной сумме - это не серьёзная проблема вообще!
Вот только вчера был у меня аналогичный диалог с поддержкой Яндекса - между строк всё это на все 100% читалось!
Такой манипуляцией пользуются все популярные поисковики! Даже судебные дела уже против гугла были!
Раз исключили конкретный браузер (а не наоборот - прописали доступные конкретные браузеры) - то, скорее всего, это специальная "закладка" - чистый протест! Никаких технических фишек тут нет!
На свалках сейчас много чего ценного находят... а кто-то до сих пор ищет старый HDD c миллионами биткойнов - намайненных около 20 лет назад...
Не надо только путать тёплое с мягким: поисковик, дисковое хранилище, облачные сервисы и браузер!
Просто для разных задач - подходят разные решения!
Есть, конечно, такая идея на будущее - по обходу блокировки по протоколу - это динамически настраиваемые протоколы - когда для каждого клиента можно условно создать свой протокол. И тут AI технологии могут сыграть очень важную роль!
Но - в отвертку может прийти запрет всего неизвестного - всех не известных протоколов! Да - будет выходить новый софт, не связанный с VPN - но его протоколы могут анализироваться и разрешаться по необходимости! Да - задержка будет большая - но такая стратегия тоже возможна - и тут, для ускорения анализа, как раз AI технологии тоже будут очень полезны! Ну и да - мощности для анализа трафика по миллионам протоколов потребуются запредельные - а скорости трафика снизятся конкретно! Тут уже, скорее, всем, кому это будет важно - реально будет проще транслировать себя целиком туда - где нет этих блокировок - ибо для них перспективы жизни в таком обществе вряд ли вообще будут приемлемы (не из-за блокировок даже - а из-за общей тенденции - ради которой и устраиваются эти блокировки)!
В ответку на ответку - блокируемы трафик можно пробовать маскировать под неблокируемый - т.е. под разрешённые протоколы - сейчас есть много таких, мне первым делом приходят на ум игры (вспоминаю сериал Адаптация) - где под видом легального трафика можно пропихивать блокируемый! Конечно скорости резко упадут... и о рантайме навряд ли можно будет говорить!
Но и тут, могут найтись, способы блокировки.... как и способы дальнейшего обхода! Но тут надо понимать - кому нужны будут такие сложности преодоления - обычным людям, скорее уже будет куда проще себя перенести (ну если границы так же не начнут блокировать - что вполне себе возможно на таком уровне социального безумия)! так что, дальнейшее сопротивление блокировкам - это уже уровень шпионажа и криминала! Больше никому так напрягаться не захочется....
Проблема в том, что VPN-трафик можно распознавать и блокировать. Это не просто и очень ресурсоёмко - но это не значит, что не решается!
В обще-то RDP трафик тоже можно распознавать и блокировать - но это совсем дргая тема - а пока РКН у нас с VPN борется - и руки (и мощности) до RDP - не скоро дойдут - власть скорее сменится... хотя там ещё тоже не ясно - чего ждать!
Так что готовьтесь лучше к худшему - покупайте чемоданы - пока их ещё не блокируют их приобретение!
Видимо придали сервису отрицательное ускорение!
В случае текста:
Знать язык программирования
Уметь читать текст
Уметь набирать текст на клавиатуре
Уметь мыслить связанными терминами
Знать стандартную библиотеку доступных типов и методов платформы
В случае изображения:
Знать символику графических представлений
Знать условные графические обозначения и паттерны
Знать правила связывания блоков и общую логику их взаимодействий
Уметь читать текст
Уметь набирать текст на клавиатуре и/или пользовать визуальными контролами для выбора нужных значений
Уметь мылить визуальными графическими представлениями как связзной структурой
Уметь хотя бы в общих чертах визуализировать схемы мышью
Быть хотя бы знакомым с графовыми и сетевыми структурами
Владеть библиотекой компонент как в текстовом так и в визуальном представлении
Владеть инструментарием платформы для визуализации и выбора компонент
Может что-то ещё - сходу сложно всё консолидировать!
Графическая схема на почти на два порядка сложнее в восприятии и начертании чем текст слева (но уточню - что люди разные - и кому-то может оказаться наоборот - но это, скорее исключение)!
Текст внизу сложный - но он тоже проще чем графическая схема. Но его сложность обусловлена лишь особенностями выбора библиотек и синтаксического сахара конкретного ЯП - текстовые ЯП позволяют писать куда проще. Ещё не известно сколько настроек скрыто за графическими элементами внутри их свойств!
На моём ЯП 5-го поколения код был бы такой
Да-да - я потом вспомнил, что писали...
А я, у себя, заметил, что каое-что упустил из вида. У меня ноты играются друг за другом (кроме аккорда) - строго последовательно.... я не пока предусмотрел их полифонию. Не то чтобы совсем не предусмотрел - у меня скорее есть модель многоголосой отдельными партиями, но в формате ввода нот я не предусмотрел наслоения нот по их длительностям. Хотя.... вот нашёл - в формате для трекерной музыки я это вскользь описал в черновом варианте так
ещё один вариант записи нот из мира трекерной музыки – важное отличие: тут не задаётся напрямую длительность ноты – она звучит, пока явно не будет сброшена или не начнётся другая (ну если, нота зациклена – иначе звучит до своего конца и всё) – и тут каждая позиция имеет фиксированную длину тактов звучания (это всё настраивается), пропуск тактов «--» (обязательно отделено от нот) или «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# - только на выходе динамическая числовая величина, а параметры выполнения так же зависят от не статичных значений переменных)!
Что для вас украшательства - для меня важные атрибуты исполнения.
Как уже написал ранее - одно дело - просто оформить ноты, которое далее в своей манере будет исполнять человек (кстати не обязательно - с вариативной интонацией может, в принципе, сыграть и робот). Другое дело - это сразу описывать произведение - готовое к немедленно автоматическому рендерингу в поток звука - для прослушивания / записи / исполнении в реальном времени на концерте (тут вообще нужно очень быстро и аккуратно всё вводить) - т.е. тут робот играет сразу - и имеет смысл задать все музыкальные нюансы исполнения какие потребуется!
Ну и не только мелизмы и штрихи сложно вводить! Порой сложные пассажи - это часть музыкального произведения! И я хочу стремиться упростить их ввод!
Вы зрите в корень - вся эта канитель по поводу Формата текстового описания (или визуальной(го)... эээ... конфигурирования) - это всё в первую очередь для удобства ввода, и удобство восприятия (чтения/анализа) человеком (впрочем у текстовых способов относительно графических есть и некоторые другие преимущества, но между собой в основном в остальном они будут равны). Да и в первую очередь, всё-таки именно удобство ввода - так как затем представление уже можно оформить в любой удобной, на данный момент для данного человека, форме!
Но это удобство - это очень обширная вещь - за ней стоит очень много нюансов. Этот как - вот раньше программы вводили машинными кодами кнопками, потом придумали перфокарты/перфоленты, потом появился ассемблер, Алгол, Си, Бейсик, Ява, Питон - формально всё это эволюция удобства ввода!
Собственно и свой ЯП "ORANGE" я задумал именно из-за того, что меня не устроило удобство ни графических систем ввода музыки, ни имеющихся ЯП кодирования (статья один и два)
И я изначально ставлю задачу так:
Возможность вводить музыка в разных текстовых форматах, в т.ч. определять свои - для максимизации удобства персонального ввода. В том числе так - чтобы музыкальный код можно было вводить непосредственно во время исполнения - в реальном временем (т.е. на "концерте") - это вообще очень сложная вещь в реализации (тут ещё со стороны IDE нужна нехилая поддержка)!
Иметь возможность гибкого повторного, в т.ч. параметрического использования музыкальных паттернов, в т.ч. через из автоматическое преобразование; в т.ч. из библиотек
Иметь возможность легко описывать специфические техники игры, присущие различным инструментам; в т.ч. техники с чётко выстроенными периодическими последовательностями, так и с нечётко
Иметь возможность вводить музыку не нотами, а математическими формулами преобразований звука (и активно применять операторы поля информатики)
Иметь возможность вводить музыку не только сухой выверенной партитурой, но с внесением музыкального окраса, натуральностью и неповторимостью звучания, как за счёт нарочитых огрехов воспроизведения, так и заложенной вариабельностью импровизации
Иметь возможность описывать сложноструктурированную вариативную музыку - которая никогда не будет сыграна идентично
Иметь возможность эффективно алгоритмически описывать наслаивания как разных звуковых голосов, так и разные эффектов, накладываемых позиционно или параллельно основной партитуры
Иметь возможность эффективно и наглядно проводить отладку музыкального кода, в т.ч. в реальном времени исполнения - это тоже достаточно сложная вещь в реализации (тут со стороны IDE нужна серьёзная поддержка)!
А насчёт альтернативы ввод в куче редакторов - так в том и дело - что реально разных вариантов раз два и обчёлся! А удобство среди них не каждый себе найдёт... я, вот, не нашёл
Дело не в этом - дело в том, что нечего видеть - сторонники визуального программирования вообще не приводят таких аргументов - либо делают это так не умело, что зашоренный вгзляд "текстовых" разработчиков их в упор не видит.
Если Вы посмотрите мои комментарии - то заметите, что мои взгляды очень широкие - и я пытался даже отчасти защищать визуальное программирование - и приводить свои аргументы о то, как эффективно его можно использовать!
Почти уверен, что конструктивного диалога не получится -
изгоипредставители узких проф. сообществ обычно очень критично настроены против "неверных" вторженцев! Просто выльют ушат грязи и пошлют куда подальше!Замечу - что ни разу не критиковал LabView - если Вам удобно, и нет того, кто смог бы Вам показать лучшую альтернативу - пользуйтесь (кому нравится photoshop, кому-то и paint сгодится - и я не уточняю кто здесь кто) - и получайте удовольствие! Но Вы же постулируете нам всем такое будущее - но не обоснуете это никак...
Вообще не понял Ваш вопрос
Нейролингвистические генеративные системы я использую только для кодирования программного кода!
Честно - пробовал картинки рисовать - ничего толкового не вышло - но, наверное, я просто "не умею их готовить" - это чисто мой косяк. Предвкушаю Ваш ответ - что и визуальное программирование я просто "не умею готовить" - и будете правы! Но всё же, я пытаюсь анализировать ситуацию так глубоко, насколько хватает моего опыта - привожу обоснованные аргументы, и пока не вижу обоснованных контр аргументов!
Я Вас не минусовал. Ну а чтобы не получать минуса от других - попробуйте всё-таки точнее излагать мысли и конкретнее отвечать на вопросы - того глядишь и карма поправится! Хотя... на хабре чаще любят необоснованно минусовать - чем плюсовать - с этим пока приходится мириться - особенно если Вы не такой как там амёбная масса - которая ставит минуса на хабре...
К сожалению - все Ваши ответы - выстрел в воздух... ибо говорил я совсем о другом, и не смотрел пристально в стороны LabView - а мысли более обобщённо!
Говоря о библиотеках - я говорил и узкоспециализированных (но, впрочем и об обобщённых - но при условии, когда архитектуре выстраивается от частного конкретного - к общему абстрактному, но очень гибкому, чтобы можно было в сановном логику выстраивать через общие абстрактное - чтобы применять обобщённые библиотеки) прикладных библиотеках для торгового робота (или какой ещё специализированной прикладной системы)! Ну и они должны быть хорошо задокументированы (в том числе, хотя бы, самодокументированы).
Говоря о кодогенгераторах - я имел в виду глубину перехода от абстракций - к конкретным инструкциям! Чем круче база статических анализаторов и кодогенераторов - тем менее системный алгоритм надо писать - удаляясь от внутренней технической части робота или иной прикладной системы, и тем больше модно сосредоточиться на общей прикладной логике и процессах взаимодействий сложных узлов и людей!
Говоря об отладчиках - тут я не понял Ваши мысли. Может пояснить? Я говорил - что прикладной код должен сейчас, и тем более в будущем, иметь высокую способность к глубокой и высокоуровневой отладке - чтобы экономить время разработчика и повышать его информируемость! И тут я уже говорил - что у визуального представления есть свои некоторые полезные фишки для этого - но я подчеркну, что ради них нет смысла именно программировать визуально - достаточно получить построенную визуальную модуль алгоритма по иному формату описания, каким бы он ни был!
Говоря о тулзах - сейчас в IDE и текстовых процессора саммые продвинутые суппорт тулзы - по вводу анализу, рефакторингу, версионирования, прогнозируемого автоввода, автоисправления, шаблонизироания и динамического применения паттерном для текста и т.д. и т.п. визуальным средам до этого ещё расти и расти... это просто пропасть! Но... это не значит что визуальные системы не смогут это всё наверстать (но это титанический будет труд). Другое дело что на это всё уйдут не годы... минимум десятилетия а скорее всего столетия - за это время и текстовые процессоры, и, уже тем более, какие-то иные средства ввода и манипулирования информацией - дадут ещё больший скачок вперёд - т.к. пока они на пике прогресса - и большая часть людей сосредоточит свои умы именно на их развитии - и если случится устойчивый перелом - то на то, чтобы он набрал кульминационный темп - потребуется уйма времени - ибо ломка мышления и парадигм будет страшная!
Вполне себе годный вариант для текстового ввода простеньких мелодий. Но не уверен, что хорошо подойдёт для профессиональных. Просто сложные музыкальные произведения, вводимые с помощью классической нотной грамоты крайне сложны в наборе - это хорошо знают классические композиторы, например, вводящие ноты в Finale (насколько я знаю - вводить классическим путём ноты в других, более привычных современным композиторам, редактора ещё куда сложнее). Оттого и стал так популярен Piano roll - но если нужны именно классические ноты - то он не особо годится (всё равно будет много правок - тут тогда уж проще на MIDI клавиатуре наиграть и потом долго корпеть в Finale - исправляя огрехи и расставляя правильную музыкальную "пунктуацию").
Но классические ноты редко нужны современным композиторам - если надо - они сбагрят это работу музыкальным "неграм" - пусть тем в Finale корячатся... Современным "не классически " композиторам вполне хватает Piano roll (в разных вариациях + drum machine) и мультидороженный семплер + Kontakt для подключения современных программ инструментов + DSP плагины для эффектов и некоторый доп. софт для создания/обработки семплов (но этим скорее уже саунд продюсеры руководят, без них композиторы обычно берут готовые библиотеки и программы Kontakt и иногда специальные плагины для эмуляции старых синтезаторов).
Поэтому я по умолчанию и не стал делать текстовый ввод в классическом нотном стиле (хотя такой формат не проблема реализовать и подключить, хотя вру - не проблема - это как у Вас - в примитивном виде, а если нужна точная нотная грамота - это это будет жесть - но в целом решаема - но сам не планирую - разработка формата ввода свободная - если кому надо будет - пусть делает транслятор во внутренние команды, и презентёр - для визуализации и графического вывода в нужном представлении).
Я правильно понял, что у Вас аккорды через { } объединение реализованы? Тогда как решаете такую игру - когда, скажем, зажимается одна клавиша (или несколько), и в это время играются другие? При этом ещё и зажатая клавиша так же может плавно варьироваться с другой клавишей! А ещё может быть начатый аккорд - переходящий в другой аккорд, и в процессе которого берутся оба аккорда с промежуточными легато, работой педалью и т.п. В современной музыке столько интересных и сложных техник... классикам и не снилось - хотя и они тоже порой сочиняли сложные произведения!
И это мы ещё сейчас мыслим скорее в терминах клавишных инструментов а-ля класс "фортепьяно". А у музыкальных инструментов других классов (видов) куча своих особенностей построения звукосочетаний.
Поэтому я и проектирую разные гибкие форматы ввода - чтобы подстроиться под технику разных инструментов. Я тут неспец по мультиинструменталке - но вот, хотя бы про гитары, или в общем случае - про класс "щипковые струнные" инструменты - там доступно столько хитрых техник исполнения (XX век был веком расцвета струнных инструментов и техник игры на них; впрочем клавишные в лице синтезаторов не шибко отставали по вариации звучания - но там техник не так много новых появилось), которые не доступны для исполнения на клавишных инструментах. И Piano roll тут вообще бессилен - а нам предлагают даже в Kontak писать мелодию для струнных через него... фу....
Так что проблема описания сложных аккордов и прочих безымянных техник гармонизации - это очень непростой вопрос! Он даже на нотном стане непростой...
Помимо аккордов продумывать и удобный ввод таких вещи как:
Музыкальные штрихи
Мелизмы
Сложные пассажи
И некоторые другие (о которых я не знаю)
Это техники для фортепиано - а у других инструментов свои хитры техники, которые тоже как-то надо вводить!
Обоснуете? Выше я тут уже приводил аргументы против графических ЯП! И привёл лишь капельку аргументов за! Некоторые из комментирующих так же привели капельку аргументов за и против. Но в целом - я тут пока не вижу значимых аргументов за графическое программирование, тем более, если говорить о далёком будущем - что там такого должно быть, чтобы визуальная разработка заметно перевесила иные способы (кстати, не обязательно текстовые - если уже говорите о далёком будущем, хотя тогда стоит хорошо подумать - какие ещё могут быть альтернативы)? А не просто визуальные системы станут лишь подспорьем для других способов
Замечу, что и визуальная разработка тоже может иметь много разных вариаций модели представления. Даже (чаще всего в комментариях рассматриваемые) диаграммы - могут иметь совершенно разные форматы. Вы за какой?
Для визуализации вариации 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.
Вот серьёзно думаю заменить символ "+" для формирования аккордов на что-то другое - чтобы не путать со смещением октав, например на "*" - просто "+" уже привычен для клавиатурных аккордов "сочетаний горячих клавиш"