А, вот, куда сейчас развиваются музыкальные редакторы (априори визуальные) - мне категорически не нравится
Мне тоже не нравится - раздражает, что не могу скопировать ноты в буфер обмена из одной программы и вставить в другую. MusicXML конечно подходит для такого, только он слишком жирный, чтобы писать на нём с нуля.
Bool? Enabled = CustomOptions["Allow"] ?? (Object as ICheckable)?.Checked; Enabled ??= A?.B?.C?.Checked ?? true; CustomOptions["Allow"] = Enabled; //A?.B?.C?.Checked ??= Enabled; //Вот это, правда, в C# не прокатит
Вот попробует без поддержки NULL такое написать
Это выглядит, как что-то связанное с настройками. С настройками я так работаю:
var ini = new Ini(); // по умолчанию загружается с именем текущей сборки. Если его нет, то создаётся пустой
bool enabled = ini["enabled", true]; // true значение по умолчанию, если его нет в .ini файле, а заодно помогает выбрать тип перегруженного индексатора
int polyphony = ini["synth"]["polyphony", 16]; // synth это название секции в .ini файле
ini["synth"]["polyphony"] = 32;
ini.Save();
// а также можно подписаться на изменение .ini файла
// извне и сразу получать уведомления об этом
ini.SectionAdded += Ini_SectionAdded;
ini.SectionRemoved += Ini_SectionRemoved;
ini.SectionChanged += Ini_SectionChanged;
ini.ValueAdded += Ini_ValueAdded;
ini.ValueChanged += Ini_ValueChanged;
ini.ValueRemoved += Ini_ValueRemoved;
ini.EnableRaisingEvents = true;
// Ну то есть поменял значение в .ini файле
// при работающей программе,
// а она их сразу и обработала.
Этот аргумент не для вас, а для других. Понятное дело, что вы будете топить за свой ЯП всеми правдами и неправдами. И сути это не меняет - нельзя ошибиться в названии переменной, если его нельзя напечатать, а можно только выбрать из списка. Нельзя ошибиться с пропущенной кавычкой, если кавычек тоже нету. Нельзя перепутать "=" или "==" в условии, если "=" тоже нету. Нельзя ошибиться с разыменованием NULL в рантайме, если NULL-ов тоже нету (а вместо них есть значения/объекты по умолчанию).
А сколько времени уйдёт в визуальном редакторе размещение такого компонента на поле (так оставим в стороне вспомогательные средства быстрого ввода)
Так оставляйте в стороне и вспомогательные средства IDE для быстрого ввода в виде автодополнения, подсветки синтаксиса и проверки орфографии, а то как-то нечестно получается.
А я уверен прямо в обратном. Но для разрешения этого спора конечно же нужно мнение со стороны. Несмотря на то, что мой проект пока ещё закрытый, я его использую для вполне реальных проектов. Например, если вы вобъёте в гугле "foobar subwoofer", то первым результатом скорее всего будет ссылка на мой плагин. Что сможете противопоставить взамен?
В контроле версий потребности пока не возникало, но за идею спасибо. А diff конечно же можно сделать - хоть текстом, хоть графикой. Внутри же это самые обычные .NET объекты, через рефлексию можно запросить значение полей и сравнивать их. Через ту же рефлексию весь этот граф можно привести к полностью текстовому виду с абсолютно идентичной функциональностью, в будущем планирую реализовать.
Да, при визуализации вполне допустимо - но, опять же, очень спорное решение - усложняет понимание схемы!
Ну вот тут кто-то жаловался на спагетти - так это спорное решение разгружает спагетти. И при желании можно отдельную визуализацию таких связей сделать, если уж на то пошло. Ну а задание через параметры потому, что не каждый модуль может выступать в качестве синтезатора, а только тот, кто поддерживает соответствующий интерфейс. И в выпадающем списке ничего лишнего не будет.
Главное преимущество визуального программирования - отсутствие необходимости именования переменных/объектов и ещё больше возможностей для инкапсуляции.
Вот ещё один пример - синтезатор, на котором можно играть как с миди-, так и с обычной клавиатуры. При этом звук идёт одновременно на два разных устройства - один допустим в зал, другой в монитор. И обратите внимание - графической связи между клавиатурами и синтезатором нет, она задаётся в свойствах:
А теперь давайте посмотрим, сколько то же самое займёт текстом:
var vsti = new VST("c:\\vst\\yamaha\\syxg50.dll");
var kbd = new KeyboardInput();
kbd.KeyPressed += OnKeyPressed;
var midiin = new MidiIn();
midiin.MessageReceived += OnMessageReceived;
var wasapi1 = new WasapiOut("Динамики (Realtek High Definition Audio)");
wasapi1.FillBuffer += OnFillBuffer1;
var wasapi2 = new WasapiOut("LG ULTRAGEAR (Аудио Intel(R) для дисплеев)");
wasapi2.FillBuffer += OnFillBuffer2;
...
И это просто объявление объектов, без какой-либо обработки миди-сообщений и копированию данных из одного буфера в другой (и хорошо если эти буферы будут одного размера). А чтобы в визуальном редакторе создать объект - даже контекстное меню вызывать не потребуется, потому что для каждого объекта предусмотрено клавиатурное сокращение, например "kbd" или "midiin", после чего он появляется в позиции курсора.
Вкратце: партитура разбивается на отдельные музыкальные фразы, оформленных в виде текстовых блоков с заголовком, например:
[гамма1] до ре ми фа соль ля си +до
[гамма2] до -си ля соль фа ми ре до
Я отказался от явного задания октавы в пользу контекста и служебных операторов. В данном примере "+" значит перескок на следующую октаву, а "-" соответственно вниз. Ноты октавы разбиваются в зависимости от тональности, до-мажор по умолчанию, другие задаются служебным оператором @key:Am
Длительность задаётся справа от ноты в виде модификатора с умножением и/или делением:
до/4 ре/4 ми*3/2
Ноты можно объединять в группы, чтобы задать модификатор один на всех:
(до ре ми)*2/3 // триолька
Также для группы можно задать количество повторений:
(до ре ми)x3 // то же, что и до ре ми до ре ми до ре ми
Можно задать громкость для каждой ноты:
до'100 ре'50 ми'10
Также к ноте можно привязять произвольное количество атрибутов, которые секвенсор или синтезатор при желании сможет обработать:
до<vibrato:3,detune:30,pan:-1>
Диезы, бемоли - по классике:
до# до&
Но можно их ставить перед нотой, а тогда его действие продлится до следующего такта (по стандарту нотной записи). В качестве конца такта выступает символ "|" (ну а какой же ещё). В этом случае потребуется бекар, для него я выбрал символ "%".
Помимо символьного обозначения нот можно использовать числа для хроматических отклонений от последней известной:
до 2 4 // то же, что и до ре ми
Ноты можно объединять в аккорды фигурными скобками:
{до ми соль +до} // прозвучат одновременно
По умолчанию, когда начинается следующая нота, предыдущая завершается. С помощью префикса "~" её можно оставить звучать до явного завершения префиксом "!". А "!!" завершает все звучащие ноты сразу:
~до ~ми !до ~соль !!
Вместо этого можно использовать несколько голосов, располагая их друг над другом:
:[1] . . си ~ :[2] . съ ~ ~ :[3] ми ~ ~ ~
Точка это пауза, одиночная тильда - продолжение звучания предыдущей ноты. Для ноты соль здесь использовано двух-буквенное сокращение, для всех нот также можно использовать стандартные латинские обозначения c d e f g а h.
Ну и таким образом можно нативно гитарные табы прописывать:
проектирую свой собственный ЯП для создания музыки под рабочим названием "Orange"
На самом деле в этой области ещё непаханное поле. Я тоже недавно накидал черновик спецификации для аналогичной задачи, тоже потому, что ни одно из существующих решений не зашло. Как минимум, чтобы иметь возможность русскими буквами писать "ля ля ля фа" в перемешку с гитарными и ударными табулатурами.
Силовые тренировки - за, но в зал ходить не хочется. Уже давно нашёл для себя гири, для которых 5-10 минут в день достаточно, чтобы наглядно ощутить прогресс и при этом не упарывать свой организм в хлам ради стереотипной внешности. Ну, ещё раз в месяц чуть более длительные тренировки устраиваю, с подтягиваниями, приседаниями и аналогичным. А штанга - это гарантированная травма, рано или поздно.
У меня тоже есть свой собственный визуальный язык программирования, вот так выглядит:
Описанная в статье проблема в том, что визуальное программирование идеально подходит для data-flow, а его пытаются пихать в control-flow. Равно как и наоборот, программирование сложной DSP-логики чисто текстом это боль и страдания. Нужно просто правильно декомпозировать задачу и выбирать подходящие инструменты, только и всего.
Ну опять же - такие задачи обычно в фоновом режиме выполняются. Никто в здравом уме не втыкает в монитор в течение часа, наблюдая за шкалой прогресса. Критично - это когда архив нужно делать каждый час, а время на создание этот самый час превышает. Или когда данные сжимаются перед отправкой по сети - суммарное время должно быть меньше, чем при передаче просто несжатых данных.
А 30% прироста можно получить просто используя компилятор от Intel (я пробовал). Который может делать несколько вариантов оптимизации кода в зависимости от платформы, на которой этот код запускается. И прославившийся тем, что АМД в эти варианты не входила)
Тут может помочь больше памяти и более быстрый винт. И опять же вопрос - стоят ли эти 15 минут дополнительных вложений в 1000К ₽ или дешевле просто чай попить, пока оно там компилируется.
Не суть. Я потому и предпочитаю говорить "в", а не "на", потому что это более интуитивно понятный критерий. Оптимизация на ассемблере в наше время это прежде всего что? Это прежде всего SSE, ускорение в 2 раза, AVX, ускорение в 4 раза, и FPU, ускорение за счёт хранения промежуточных результатов в стеке сопроцессорра, а не в памяти.
Ассемблерная реализация примерно на 30% быстрее исходной!
Восклицательный знак здесь совершенно неуместен - 30% это совершенно незначительный результат по соотношению ускорение/затраченное время. Я не берусь за асм, если не уверен в хотя бы 200% процентах (то есть 2-кратного ускорения), а в целом достигал 40-кратного ускорения.
Мне тоже не нравится - раздражает, что не могу скопировать ноты в буфер обмена из одной программы и вставить в другую. MusicXML конечно подходит для такого, только он слишком жирный, чтобы писать на нём с нуля.
Это выглядит, как что-то связанное с настройками. С настройками я так работаю:
Этот аргумент не для вас, а для других. Понятное дело, что вы будете топить за свой ЯП всеми правдами и неправдами. И сути это не меняет - нельзя ошибиться в названии переменной, если его нельзя напечатать, а можно только выбрать из списка. Нельзя ошибиться с пропущенной кавычкой, если кавычек тоже нету. Нельзя перепутать "=" или "==" в условии, если "=" тоже нету. Нельзя ошибиться с разыменованием NULL в рантайме, если NULL-ов тоже нету (а вместо них есть значения/объекты по умолчанию).
Так оставляйте в стороне и вспомогательные средства IDE для быстрого ввода в виде автодополнения, подсветки синтаксиса и проверки орфографии, а то как-то нечестно получается.
Это, кстати, ещё одно преимущество визуального программирования - ошибки подобного рода там невозможны в принципе.
А я уверен прямо в обратном. Но для разрешения этого спора конечно же нужно мнение со стороны. Несмотря на то, что мой проект пока ещё закрытый, я его использую для вполне реальных проектов. Например, если вы вобъёте в гугле "foobar subwoofer", то первым результатом скорее всего будет ссылка на мой плагин. Что сможете противопоставить взамен?
В контроле версий потребности пока не возникало, но за идею спасибо. А diff конечно же можно сделать - хоть текстом, хоть графикой. Внутри же это самые обычные .NET объекты, через рефлексию можно запросить значение полей и сравнивать их. Через ту же рефлексию весь этот граф можно привести к полностью текстовому виду с абсолютно идентичной функциональностью, в будущем планирую реализовать.
И вы хотите сказать, что эта простыня текста проще в понимании и набивается также в течении максимум десяти секунд?
Ну вот тут кто-то жаловался на спагетти - так это спорное решение разгружает спагетти. И при желании можно отдельную визуализацию таких связей сделать, если уж на то пошло. Ну а задание через параметры потому, что не каждый модуль может выступать в качестве синтезатора, а только тот, кто поддерживает соответствующий интерфейс. И в выпадающем списке ничего лишнего не будет.
Главное преимущество визуального программирования - отсутствие необходимости именования переменных/объектов и ещё больше возможностей для инкапсуляции.
Вот ещё один пример - синтезатор, на котором можно играть как с миди-, так и с обычной клавиатуры. При этом звук идёт одновременно на два разных устройства - один допустим в зал, другой в монитор. И обратите внимание - графической связи между клавиатурами и синтезатором нет, она задаётся в свойствах:
А теперь давайте посмотрим, сколько то же самое займёт текстом:
И это просто объявление объектов, без какой-либо обработки миди-сообщений и копированию данных из одного буфера в другой (и хорошо если эти буферы будут одного размера). А чтобы в визуальном редакторе создать объект - даже контекстное меню вызывать не потребуется, потому что для каждого объекта предусмотрено клавиатурное сокращение, например "kbd" или "midiin", после чего он появляется в позиции курсора.
Вкратце: партитура разбивается на отдельные музыкальные фразы, оформленных в виде текстовых блоков с заголовком, например:
[гамма1]до ре ми фа соль ля си +до
[гамма2]до -си ля соль фа ми ре до
Я отказался от явного задания октавы в пользу контекста и служебных операторов. В данном примере "+" значит перескок на следующую октаву, а "-" соответственно вниз. Ноты октавы разбиваются в зависимости от тональности, до-мажор по умолчанию, другие задаются служебным оператором
@key:AmДлительность задаётся справа от ноты в виде модификатора с умножением и/или делением:
до/4 ре/4 ми*3/2Ноты можно объединять в группы, чтобы задать модификатор один на всех:
(до ре ми)*2/3 // триолькаТакже для группы можно задать количество повторений:
(до ре ми)x3 // то же, что и до ре ми до ре ми до ре миМожно задать громкость для каждой ноты:
до'100 ре'50 ми'10Также к ноте можно привязять произвольное количество атрибутов, которые секвенсор или синтезатор при желании сможет обработать:
до<vibrato:3,detune:30,pan:-1>Диезы, бемоли - по классике:
до# до&Но можно их ставить перед нотой, а тогда его действие продлится до следующего такта (по стандарту нотной записи). В качестве конца такта выступает символ "
|" (ну а какой же ещё). В этом случае потребуется бекар, для него я выбрал символ "%".Помимо символьного обозначения нот можно использовать числа для хроматических отклонений от последней известной:
до 2 4 // то же, что и до ре миНоты можно объединять в аккорды фигурными скобками:
{до ми соль +до} // прозвучат одновременноПо умолчанию, когда начинается следующая нота, предыдущая завершается. С помощью префикса "
~" её можно оставить звучать до явного завершения префиксом "!". А "!!" завершает все звучащие ноты сразу:~до ~ми !до ~соль !!Вместо этого можно использовать несколько голосов, располагая их друг над другом:
:[1] . . си ~:[2] . съ ~ ~
:[3] ми ~ ~ ~
Точка это пауза, одиночная тильда - продолжение звучания предыдущей ноты. Для ноты соль здесь использовано двух-буквенное сокращение, для всех нот также можно использовать стандартные латинские обозначения c d e f g а h.
Ну и таким образом можно нативно гитарные табы прописывать:
[:1 @root:64] 0 ~ ~ ~|5 ~ 7 ~ |[:2 @root:59] 1 ~ ~ ~|5 ~ 6 ~ |
[:3 @root:55] 2 ~ ~ ~|5 ~ . . |
[:4 @root:40] . . . .|. . . . |
[:5 @root:35] 0 ~ ~ ~|0 ~ ~ ~ |
[:6 @root:30] . . . .|. . . . |
Как-то так.
Не вопрос, но чуть попозже. Может вообще стоит в виде отдельной статьи оформить, раз нашёлся хотя бы один человек, которому это тоже интересно)
На самом деле в этой области ещё непаханное поле. Я тоже недавно накидал черновик спецификации для аналогичной задачи, тоже потому, что ни одно из существующих решений не зашло. Как минимум, чтобы иметь возможность русскими буквами писать "ля ля ля фа" в перемешку с гитарными и ударными табулатурами.
Силовые тренировки - за, но в зал ходить не хочется. Уже давно нашёл для себя гири, для которых 5-10 минут в день достаточно, чтобы наглядно ощутить прогресс и при этом не упарывать свой организм в хлам ради стереотипной внешности. Ну, ещё раз в месяц чуть более длительные тренировки устраиваю, с подтягиваниями, приседаниями и аналогичным. А штанга - это гарантированная травма, рано или поздно.
У меня тоже есть свой собственный визуальный язык программирования, вот так выглядит:
Описанная в статье проблема в том, что визуальное программирование идеально подходит для data-flow, а его пытаются пихать в control-flow. Равно как и наоборот, программирование сложной DSP-логики чисто текстом это боль и страдания. Нужно просто правильно декомпозировать задачу и выбирать подходящие инструменты, только и всего.
Ну опять же - такие задачи обычно в фоновом режиме выполняются. Никто в здравом уме не втыкает в монитор в течение часа, наблюдая за шкалой прогресса. Критично - это когда архив нужно делать каждый час, а время на создание этот самый час превышает. Или когда данные сжимаются перед отправкой по сети - суммарное время должно быть меньше, чем при передаче просто несжатых данных.
А 30% прироста можно получить просто используя компилятор от Intel (я пробовал). Который может делать несколько вариантов оптимизации кода в зависимости от платформы, на которой этот код запускается. И прославившийся тем, что АМД в эти варианты не входила)
Тут может помочь больше памяти и более быстрый винт. И опять же вопрос - стоят ли эти 15 минут дополнительных вложений в 1000К ₽ или дешевле просто чай попить, пока оно там компилируется.
Не суть. Я потому и предпочитаю говорить "в", а не "на", потому что это более интуитивно понятный критерий. Оптимизация на ассемблере в наше время это прежде всего что? Это прежде всего SSE, ускорение в 2 раза, AVX, ускорение в 4 раза, и FPU, ускорение за счёт хранения промежуточных результатов в стеке сопроцессорра, а не в памяти.
Восклицательный знак здесь совершенно неуместен - 30% это совершенно незначительный результат по соотношению ускорение/затраченное время. Я не берусь за асм, если не уверен в хотя бы 200% процентах (то есть 2-кратного ускорения), а в целом достигал 40-кратного ускорения.
Хмель же (семейства Коноплёвые).