Знать стандартную библиотеку доступных типов и методов платформы
В случае изображения:
Знать символику графических представлений
Знать условные графические обозначения и паттерны
Знать правила связывания блоков и общую логику их взаимодействий
Уметь читать текст
Уметь набирать текст на клавиатуре и/или пользовать визуальными контролами для выбора нужных значений
Уметь мылить визуальными графическими представлениями как связзной структурой
Уметь хотя бы в общих чертах визуализировать схемы мышью
Быть хотя бы знакомым с графовыми и сетевыми структурами
Владеть библиотекой компонент как в текстовом так и в визуальном представлении
Владеть инструментарием платформы для визуализации и выбора компонент
Может что-то ещё - сходу сложно всё консолидировать!
Графическая схема на почти на два порядка сложнее в восприятии и начертании чем текст слева (но уточню - что люди разные - и кому-то может оказаться наоборот - но это, скорее исключение)!
Текст внизу сложный - но он тоже проще чем графическая схема. Но его сложность обусловлена лишь особенностями выбора библиотек и синтаксического сахара конкретного ЯП - текстовые ЯП позволяют писать куда проще. Ещё не известно сколько настроек скрыто за графическими элементами внутри их свойств!
На моём ЯП 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.
Вот серьёзно думаю заменить символ "+" для формирования аккордов на что-то другое - чтобы не путать со смещением октав, например на "*" - просто "+" уже привычен для клавиатурных аккордов "сочетаний горячих клавиш"
MusicXML - он не для ручного ввода - а для автоматикой (в т.ч. кроссплатформенной) интеграции - как раз для копи/паста мог сгодиться...
Так же MusicXML априори очень гибкий и расширяемый формат. Например, в "ORANGE" помимо общих форматов музыкальных потоков WAVE и MIDI возможны и потоки в других форматах (пока сугубо теоретические - этот вопрос ещё не проработан, но заложен изначально), среди которых может быть и MusicXML; а так же запланирован (но может откажусь и буду расширять MusicXML) проприетарный открытый формат (кстати, рассматривалась база XML, JSON, Protobuf) - для более расширенного управления компонентами (как в качестве внутреннего протокола, так и для взаимодействия со сторонними компонентами). Просто у меня запланировано куда более сложное командное взаимодействие, чем набор MIDI-событий, в т.ч. с целью управления параметрами и техниками звукоизвлечения комплексных компонент (а-ля какие использует Kontakt)
мой пример было не про опции, а про работу с null значениями - я специально старался его абстрактно написать, а "CustomOptions["Allow"] " просто привёл как понятный источник null значения, но я не указывал его физическую природу - это может быть и карта "ключ-значение" (фиг его знает откуда полученная) - или обращение какому-либо хранилищу - хоть локальному, хоть БД, или какой-либо ещё комплексный сервис - который пытает получить значение из данных, собираемых их различных источников. ИМХО - алгоритму основной логики это всё должно быть сугубо "фиолетово" - у него есть источник "CustomOptions" - вот там он будет искать значение. А если его там нет - у него есть некий процесс иного поучения этого значения, которые тоже не гарантирует успех - и только затем значение берётся из кода - для случая, когда без него дальше никак не обойтись, но по какой-то непонятной причине оно так и не было получено!
Ну а в финале - передаём (во втором случае пытаемся) значение в нужные объекты - чтобы так больше не "мучиться" и для того, что это значение ещё где-то важно должно быть - если это "где-то" существует! Не вдаваясь в подробности того - как эти все вспомогательные объекты устроены!
Понятное дело, что вы будете топить за свой ЯП всеми правдами и неправдами.
Я не собираюсь топить за свой ЯП! Как и топить другие системы (ну кроме 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# не прокатит
Так оставляйте в стороне и вспомогательные средства IDE для быстрого ввода в виде автодополнения, подсветки синтаксиса и проверки орфографии, а то как-то нечестно получается
Если внимательно читали - то я при оценке времени так и сделал. И указал - что с данными средствами будет и ещё быстрее и надёжнее
Просто Ваш аргумент он не имеет значимой силы
Интересно - кто минус моему комментарию выше поставил - за что (если это вы просто в отместку - то я не минусовал ваш комментарий)
Тут всё зависит от подходов к разработке и среды. Чем жёстче подходы - тем меньше комфорта и универсальность - но выше контроль.
А подобные опечатки текстовые IDE в 99.98% случае сами находят ещё на стадии окончания ввода слова! А некоторые продвинутые IDE ещё и сразу могут исправлять! Не говоря уже о быстрых подсказках автоподстановки - которые в умелых руках (и умелом текстовом процессоре) в более чем 80% случае просто позволяют избегать таких ошибок!
(не ключевые слова, уже определённых идентификаторов или литералов - так же будут выделяться цветом; а при мало-мальски грамотном назначении имён идентификаторов - вероятность ошибиться и из-за опечатки ввести другое имя существующего идентификатора - практически равна нулю - и современные IDE могут сразу автоматически исправлять такие опечатки)!
У визуальных сред куча своих проблем - часть я в комментариях к этой статье уже описал - но это далеко не полный список!
То же зарезервированное слово для определения сущности "instrument" - в текстовом редакторе вводится за 1.5-2 секунды (кото-то и быстрее введёт, я уж не говорю о шаблонах и копипасте, и быстрых подсказках ввода) - ошибка в тестовых процессорах будет видна сразу (это же ключевое слово - оно не будет выделено соответствующим образом) - и на её осознание и исправление (требующееся очень редко) уйдёт ещё секунды 2-3.
А сколько времени уйдёт в визуальном редакторе размещение такого компонента на поле (так оставим в стороне вспомогательные средства быстрого ввода): надо где-то нажать кнопку с командой добавления компонента, затем выбрать его из списка, или воспользоваться текстовым поиском, кликнуть по кнопке добавления, перенести его в нужное место на плоскости (а то ещё и другие компоненты подёргать) - это десятки секунд.... а потом окажется что это не тот компонент, что нужен (например, промахнулись - не туда кликнули)...
То же и про пропущенную кавычку - обычно это всё легко видно - небольшие сложности только в интерполяционных строках бывают - но были бы такие у Вас - были бы такие же проблемы, скорее всего - но это всё мелкие проблемы - и быстро исправляются.
P.S.
Вот опечатка с MIDI там где нужна WAVE именно в моём ЯП всплыла- бы только при компиляции - когда драйвер устройства WASAPI не смог бы по типам данных спрячься с типом данных, передаваемых из канала! Но это уже нюансы ЯП гибкой статической типизации - точные типы появляются только при компиляции!
Упущенный параметр "Input=InputChanel2" для "Track2" (без специально настроенных анализаторов) всплыл бы только при отладке - параметр не обязательный (как и то, что у трека может не быть входного канала данных - когда он сами их статически описывает или генерирует, или откуда-то загружает) в своём теле - внутри { }; или в трек могут напрямую отправляться инструкции из другого трека (трек сначала может динамически наполняться, а потом только воспроизводиться, или не обязательно воспроизводиться, а, скажем, выгружаться на диск в файл/БД, или передаваться в другую программу, в т.ч. по сети)!
Пропущенное указание треков, которые надо стартовать при старте проекта - это скорее нюансы дизайна ЯП - может действительно не надо стартовать никаких треков - а при старте проекта нужно выполнить сначала подготовительные алгоритмы... но можно, конечно ввести какую-то конструкцию - указывающую на это - и когда ничего нет - хотя бы выдавать предупреждение при компиляции
Для составления инструкций алгоритма работы в среде требуются знания не столько в программировании, сколько в знаниях внешней аппаратной части бинарной логики управления.
Скажу так - в этом конкретном случае лишь три проблемы:
Отсутствие правильно архитектурно подготовленных библиотек и документации к ним
Отсутствие настроенных кодогенератор, отладчиков и прочего суппорт-софта для данной среды
Я же выше написал - что системное программирование ещё долго будет с нами - и там будет править классика. Но, объёмы такого программирования будут год от года снижаться. А вот объёмы кодогенерации, в т.ч. и в области системного программирования будут год от года расти. А визуальное и декларативное программирование будут как раз стоять на фундаменте низкоуровневой кодогенерации и некоторых системных готовых библиотеках!
Я ни разу не говорил, что Ваше решение - не рабочее и не может иметь практической ценности или быть популярным в определённых кругах. А так да - только практическое применение и отзывы могут показать эффективность того или иного подхода. У меня пока нет рабочего решения :-(
Про повторное использование кода, кодогенерацию и шаблоны, и разбиение по файлам/модулям - я уже написал выше. И уверен - даже незнакомые с построением DSP-плагинов люди, сходу поймут что да как тут происходит и настраивается! Не говоря уж про строки комментариев - и прочее самодокументированние!
Да и ЯП "Orange" - задуман как куда более мощная "штука", чем просто DSP-фильтр - так что тут есть "место" для боллеплейт-кода - но всё это можно вынести в повторноиспользуемый код -или применять шаблоны! Да и с некоторым "синтаксическим сахаром" это всё можно несколько было упростить - для простых случаев
P.S. Хотя компиляция проекта в DSP-фильтр или VST-плагин - тоже вполне возможна
В случае текста:
Знать язык программирования
Уметь читать текст
Уметь набирать текст на клавиатуре
Уметь мыслить связанными терминами
Знать стандартную библиотеку доступных типов и методов платформы
В случае изображения:
Знать символику графических представлений
Знать условные графические обозначения и паттерны
Знать правила связывания блоков и общую логику их взаимодействий
Уметь читать текст
Уметь набирать текст на клавиатуре и/или пользовать визуальными контролами для выбора нужных значений
Уметь мылить визуальными графическими представлениями как связзной структурой
Уметь хотя бы в общих чертах визуализировать схемы мышью
Быть хотя бы знакомым с графовыми и сетевыми структурами
Владеть библиотекой компонент как в текстовом так и в визуальном представлении
Владеть инструментарием платформы для визуализации и выбора компонент
Может что-то ещё - сходу сложно всё консолидировать!
Графическая схема на почти на два порядка сложнее в восприятии и начертании чем текст слева (но уточню - что люди разные - и кому-то может оказаться наоборот - но это, скорее исключение)!
Текст внизу сложный - но он тоже проще чем графическая схема. Но его сложность обусловлена лишь особенностями выбора библиотек и синтаксического сахара конкретного ЯП - текстовые ЯП позволяют писать куда проще. Ещё не известно сколько настроек скрыто за графическими элементами внутри их свойств!
На моём ЯП 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.
Вот серьёзно думаю заменить символ "+" для формирования аккордов на что-то другое - чтобы не путать со смещением октав, например на "*" - просто "+" уже привычен для клавиатурных аккордов "сочетаний горячих клавиш"
Не кажется Вам, что это слишком громоздко? Время Piano roll прошло...
MusicXML - он не для ручного ввода - а для автоматикой (в т.ч. кроссплатформенной) интеграции - как раз для копи/паста мог сгодиться...
Так же MusicXML априори очень гибкий и расширяемый формат. Например, в "ORANGE" помимо общих форматов музыкальных потоков WAVE и MIDI возможны и потоки в других форматах (пока сугубо теоретические - этот вопрос ещё не проработан, но заложен изначально), среди которых может быть и MusicXML; а так же запланирован (но может откажусь и буду расширять MusicXML) проприетарный открытый формат (кстати, рассматривалась база XML, JSON, Protobuf) - для более расширенного управления компонентами (как в качестве внутреннего протокола, так и для взаимодействия со сторонними компонентами). Просто у меня запланировано куда более сложное командное взаимодействие, чем набор MIDI-событий, в т.ч. с целью управления параметрами и техниками звукоизвлечения комплексных компонент (а-ля какие использует Kontakt)
мой пример было не про опции, а про работу с 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 ) - всё время путаю
Вопрос скорее про интеграцию с платформой
Я не собираюсь топить за свой ЯП! Как и топить другие системы (ну кроме Native instruments Kontakt - уж больно она меня разочаровала (хотя шутка, бесспорно, полезная); как и разочаровало, например, и развитие Sony Acid - который теперь мультикомбайн Vega, Cakewalk - который теперь Sonar (и многие другие мультидорожечники) - но это для тех кто в курсе). И готов принять любую критику своих идей - главное чтобы было обоснование, даже если я его сочту спорным - обоснованная критика - всё равно полезная критика!. И я не пытаюсь необоснованно критиковать вашу разработку. Напротив - я всячески желаю Вам удачи с ней!
Как я выше написал - всем есть своя цена - и всего есть плюсы и минусы. И где есть минусы - их стараются "пусть порой условно и костылями" эти минусы устранять! И таких наработок для текстовых процессоров уже уйма - так что если сравнивать кодинг лет пятьдесят назад и сейчас - это будет гигантский разрыв (даже в рамках одного текстового ЯП)! Даже за последние 10 лет IDE шагнули очень далеко вперёд. А сейчас, на волне, генеративных лингвистических алгоритмов - шагнут ещё сильнее!
(Кстати, у Вас есть имена модулей, и да - вы позволяете их выбирать из списка (как, впрочем, это позволяют и быстрые всплывающие подсказки ввода) - но решаете ли Вы проблему, когда - это имя потом меняется у модуля - везде где используется переназначаться? Для визуальных систем это, правда, плёвое дело - а текстовые процессоры пришли к решениям не так давно - рефакторинг изменения и подсчёт с отображением ссылок - но 100% надёжности это не даёт... впрочем наврядлли сейчас хоть где-то есть 100% надёжность при активном повторном использовании кода и библиотек)
А, вот, куда сейчас развиваются музыкальные редакторы (априори визуальные) - мне категорически не нравится - это навороченные визуальны монстры с красивой графической обёрткой - и скудным сложным содержимым (я не буду говорить про плагины - среди которых есть и не скудные но от того не менее простые приложения)! Вот тут действительно назрела революция! Когда-то такой был Трекерный редактор, Piano roll, драмм-машина, , затем технология VST-плагинов, затем виртуальных DSP-процессоров и мультидорожечных редакторов и наконец музыкальных приложений для платформы Kontakt (ну я не все знаковые технологии в музыко-строении перечислил). Пришла пора двигаться дальше...
Вот за это всецелое УРА! Учли опыт величайшей ошибки Дейкстры! Я тоже против 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 такое написать
Если внимательно читали - то я при оценке времени так и сделал. И указал - что с данными средствами будет и ещё быстрее и надёжнее
Просто Ваш аргумент он не имеет значимой силы
Интересно - кто минус моему комментарию выше поставил - за что (если это вы просто в отместку - то я не минусовал ваш комментарий)
Тут всё зависит от подходов к разработке и среды. Чем жёстче подходы - тем меньше комфорта и универсальность - но выше контроль.
А подобные опечатки текстовые IDE в 99.98% случае сами находят ещё на стадии окончания ввода слова! А некоторые продвинутые IDE ещё и сразу могут исправлять! Не говоря уже о быстрых подсказках автоподстановки - которые в умелых руках (и умелом текстовом процессоре) в более чем 80% случае просто позволяют избегать таких ошибок!
(не ключевые слова, уже определённых идентификаторов или литералов - так же будут выделяться цветом; а при мало-мальски грамотном назначении имён идентификаторов - вероятность ошибиться и из-за опечатки ввести другое имя существующего идентификатора - практически равна нулю - и современные IDE могут сразу автоматически исправлять такие опечатки)!
У визуальных сред куча своих проблем - часть я в комментариях к этой статье уже описал - но это далеко не полный список!
То же зарезервированное слово для определения сущности "instrument" - в текстовом редакторе вводится за 1.5-2 секунды (кото-то и быстрее введёт, я уж не говорю о шаблонах и копипасте, и быстрых подсказках ввода) - ошибка в тестовых процессорах будет видна сразу (это же ключевое слово - оно не будет выделено соответствующим образом) - и на её осознание и исправление (требующееся очень редко) уйдёт ещё секунды 2-3.
А сколько времени уйдёт в визуальном редакторе размещение такого компонента на поле (так оставим в стороне вспомогательные средства быстрого ввода): надо где-то нажать кнопку с командой добавления компонента, затем выбрать его из списка, или воспользоваться текстовым поиском, кликнуть по кнопке добавления, перенести его в нужное место на плоскости (а то ещё и другие компоненты подёргать) - это десятки секунд.... а потом окажется что это не тот компонент, что нужен (например, промахнулись - не туда кликнули)...
То же и про пропущенную кавычку - обычно это всё легко видно - небольшие сложности только в интерполяционных строках бывают - но были бы такие у Вас - были бы такие же проблемы, скорее всего - но это всё мелкие проблемы - и быстро исправляются.
P.S.
Вот опечатка с MIDI там где нужна WAVE именно в моём ЯП всплыла- бы только при компиляции - когда драйвер устройства WASAPI не смог бы по типам данных спрячься с типом данных, передаваемых из канала! Но это уже нюансы ЯП гибкой статической типизации - точные типы появляются только при компиляции!
Упущенный параметр "Input=InputChanel2" для "Track2" (без специально настроенных анализаторов) всплыл бы только при отладке - параметр не обязательный (как и то, что у трека может не быть входного канала данных - когда он сами их статически описывает или генерирует, или откуда-то загружает) в своём теле - внутри { }; или в трек могут напрямую отправляться инструкции из другого трека (трек сначала может динамически наполняться, а потом только воспроизводиться, или не обязательно воспроизводиться, а, скажем, выгружаться на диск в файл/БД, или передаваться в другую программу, в т.ч. по сети)!
Пропущенное указание треков, которые надо стартовать при старте проекта - это скорее нюансы дизайна ЯП - может действительно не надо стартовать никаких треков - а при старте проекта нужно выполнить сначала подготовительные алгоритмы... но можно, конечно ввести какую-то конструкцию - указывающую на это - и когда ничего нет - хотя бы выдавать предупреждение при компиляции
Скажу так - в этом конкретном случае лишь три проблемы:
Отсутствие правильно архитектурно подготовленных библиотек и документации к ним
Отсутствие настроенных кодогенератор, отладчиков и прочего суппорт-софта для данной среды
Закостенелость мышления технического руководства
Я же выше написал - что системное программирование ещё долго будет с нами - и там будет править классика. Но, объёмы такого программирования будут год от года снижаться. А вот объёмы кодогенерации, в т.ч. и в области системного программирования будут год от года расти. А визуальное и декларативное программирование будут как раз стоять на фундаменте низкоуровневой кодогенерации и некоторых системных готовых библиотеках!
Я ни разу не говорил, что Ваше решение - не рабочее и не может иметь практической ценности или быть популярным в определённых кругах. А так да - только практическое применение и отзывы могут показать эффективность того или иного подхода. У меня пока нет рабочего решения :-(
Про повторное использование кода, кодогенерацию и шаблоны, и разбиение по файлам/модулям - я уже написал выше. И уверен - даже незнакомые с построением DSP-плагинов люди, сходу поймут что да как тут происходит и настраивается! Не говоря уж про строки комментариев - и прочее самодокументированние!
Да и ЯП "Orange" - задуман как куда более мощная "штука", чем просто DSP-фильтр - так что тут есть "место" для боллеплейт-кода - но всё это можно вынести в повторноиспользуемый код -или применять шаблоны! Да и с некоторым "синтаксическим сахаром" это всё можно несколько было упростить - для простых случаев
P.S. Хотя компиляция проекта в DSP-фильтр или VST-плагин - тоже вполне возможна