Сам был удивлён, сколько людей мыслят в духе "Мне это не нужно, есть обходные варианты, значит фича ненужная!". И одно дело просто предложить другие способы на подумать, но нет, именно ультимативно заявляется, что идея неверная.
При этом сколько уже было сказано, что функционал нужен не только программистам (это и в статье есть). А даже если и программистам, то не все проекты хочется публиковать (пусть и в приватные репы) на GitHub. Если я подключу второй компьютер и захочу поиметь все эти мелкие квазипроекты на нём, мне на всё репы заводить и git clone вызывать? Действительно, удобно.
Ну да. Есть папка на компьютере, которая синхронизируется с облаком. Но локально у меня ничего не удаляется. Отключусь от облака — локально всё на месте будет.
Кстати, забавно, что именно самые крупные сервисы облачного хранения не реализуют данную фичу: Dropbox, Google, Microsoft. Хотя реализация данной штуки, хоть, возможно, и не значительно, но была бы преимуществом перед конкурентами.
Наезд на Dropbox связан с наличием портала, куда пользователи могут публиковать идеи, с наличием самой запрашиваемой фичи и с откровенным безразличием к такой идее со стороны компании в течение 10 лет.
Вы всё верно пишите, что не стоит ждать у моря погоды. Я уже и не жду, я у себя сделал примитивное решение в виде PowerShell-скрипта, который нужно запускать. Но мне кажется неверным видеть что-то неудобное и просто молча делать костыли с мыслями "Ну ладно". Всё же встроенное решение есть самый правильный путь, Мечты...
А оффлайновый бэкап всегда есть локально на компьютере. Хотя Dropbox позволяет включать режим online-only для сохранения места на диске (и некоторые им пользуются), я всё храню автономно на своём компьютере.
Да, нужна поддержка в клиенте. Ну и на сервере по части особой работы с файлом .dbignore (или как его назовут). Про создание сторонних клиентов не подскажу, были такие сообщения в дискуссиях, но я не заметил, чтобы в итоге кто-то счёл это реальным, нужно изучить.
Сложно поверить, что их CEO до сих пор не знает о таком фича реквесте :-) Но я понял, о чём вы говорите касательно недостатка внимания к порталу с пользовательскими инициативами. И для большинства идей такое вполне может быть. Но не для самой запрашиваемой, и не 10 лет.
Про сложности реализации возможно. Хотя это и удивительно (но бывает), что такая крупная компания не может за всё это время реорганизовать код. В принципе это тоже что-то говорит о продукте и управлении им.
Т.е. они позволяют создать специальный файл .megaignore и указать паттерны для исключения. И эта компания не посчитала, как некоторые в комментариях, что это ненужный функционал. Причём сделали они его даже без громких возгласов аудитории.
Считаю пример с посудомойкой совершенно некорректным. Сервисы по облачному хранению данных оперируют файлами, поэтому вполне легитимно просить от них неких "улучшений" этих самых операций по обработке файлов. А отсеивать ненужные файлы (пользователь сам решит, что нужно, а что нет), как по мне, само собой напрашивается.
Но, разумеется, ваше мнение может не сходиться с мнением тысячи людей, желающих эту "высосанную из пальца" фичу.
Но ведь я про версионирование вообще не говорил. Лично я важные проекты, разумеется, веду в GitHub. Но ничего не должно мне запрещать хранить эти проекты ещё и в Dropbox. Вообще в статье целый абзац есть касательно того, о чём вы говорите. Но пару моментов повторю:
У меня много утилит, которые я делаю просто, чтобы разово что-то проверить или сгенерировать. Я не хочу класть их в GitHub, создавать репозиторий, выполнять какие-то команды. Мне нужен просто бэкап этих проектов, чтобы я мог на другом компьютере их сразу же поиметь при синхронизации с облаком и всё.
Обсуждаемая в статье фича нужна не только программистам (в статье про это написано).
А как оно устроено у меня, можно почитать в статье Создание .NET библиотеки от А до Я. Там и GitHub и пайплайны и релизы и документация и чего только нет. Только это не должно мне запрещать использовать Dropbox простым способом: хранить там проект и не отправлять временные файлы в облако.
Dropbox для хранения файлов. Исходники тоже файлы.
Более того, даже в рамках дискуссии по обсуждаемой идее компания довольно быстро признала, что возможность исключать файлы из синхронизации людям нужна. В статье всё это написано. Написано даже, что нужно это не только программистам с их злополучными исходниками.
Есть опыт других компаний, которые возможность игнорирования файлов предоставляют. И никто мозги ложечкой им не ест.
Я уже не говорю о том, что (повторяю написанное в статье) Dropbox сам предоставил площадку для публикации идей и вот у них на руках самая желаемая фича, и они её игнорируют.
99.99% задач связанных с MIDI - это воспроизведение MIDI.
Слишком категоричное заявление. Из моего опыта обращений пользователей это не так. Хотя, подтверждаю, задача одна из популярных.
синтезом звука занимаются VSTi и прочие программные продукты
Совершенно верно, и VSTi это уже про генерацию аудио (собственно, звука). VSTi забирает данные из MIDI Input и генерирует звук. MIDI это только про команды для синтезатора (аппратного, программного, VSTi и иже с ними), MIDI абсолютно никак с генерацией звука не связан сам по себе.
Ну вот подключил я недавно синтезатор к компьютеру и захотел с него получить квадро-звук с реверберацией из органного зала. Но стандартный миди-девайс Microsoft GS Wavetable Synth не даёт такой возможности, поэтому никак тут без низкоуровневого звука не обойтись.
Думаю, ваша проблема была какой-то иной или я чего-то не понял. Что мешает озвучивать ваш синтезатор (аппаратный, как я понимаю, речь не про генерацию MIDI из программы) любым VSTi? Зачем тут какой-то "низкоуровневый звук"?
Если же речь про озвучивание генерируемого программой MIDI, то ситуация стандартная и решается не менее стандартно через виртуальные устройства. Как я и писал выше, virtual cables это называется. Из наиболее популярных и бесплатных, наверное, loopMIDI:
создаёте в loopMIDI устройство с именем X;
выводите MIDI плейбек на этот X;
забираете данные из X в любом нужном вам VSTi (т.е. у инструмента указываете MIDI Input = X).
Заодно и ошибку в низкоуровневых алгоритмах нашёл, которую вы не захотели принимать
Принимаю. Но для пользователей функция, от того алгоритма зависящаая, работает верно.
Не нашёл, например, никакого упоминания про VSTi и устройства вывода звука, ни на каком уровне абстракции. Что заодно решило бы проблему с таймером в 1мс.
Вы путаете MIDI и Audio. MIDI playback никогда не будет без таймера. Audio будет, звук выводится на аудио-устройства посредством буфера.
Любой VSTi имеет параметр MIDI input. Это MIDI-устройство, откуда принимать даные. Стандартная практика вывода программного MIDI в VST-инструмент — виртуальные устройства (aka virtual cables). DryWetMIDI предоставляет возможность выводить MIDI.
Значит, это нужно делать самому, и вникать в низкоуровневую реализацию тоже самому, а тогда зачем вот это вот всё.
Процент задач, в которых нужно вникать в низкоуровневую реализацию намного меньше прикладных задач, в которых получить ноты или выполнить их квантизацию есть насущные проблемы.
Так я и есть тот самый "благодарный пользователь" Sanford и MidiSharp.
Разумеется, каждый сам выбирает себе инструмент, который ему больше нравится.
Возвращаясь в русло статьи: в обеих этих библиотеках нет предлагаемого вами подхода — каждый класс класть в отдельное пространство имён. Повторюсь, вы первый, кто такое практикует. Это любопытно, и в любом случае спасибо за комментарий.
Я за критику, но конструктивную. В прошлой статье были комментарии, указывающие на минусы подхода с кастомными структурами. Очень благодарен этим замечаниям, я их добавил в статью даже.
Да, потому что в стандарте MIDI есть понятие "событие".
Да, об этом сказано в статье:
В MIDI есть события. При этом у каждого задано смещение во времени (в неких тиках) относительно предыдущего. Но в музыке, разумеется, никто не оперирует MIDI-событиями
По поводу
Поэтому правильные (и логичные) нэймспейсы будут Midi.Event.NoteOn, Midi.Event.NoteOff, Midi.Event.AllNoteOff и т.д.
не согласен категорически. Мало того, что я вообще в первый раз вижу отдельные пространства имён под каждый класс (пользователи за это будут вам очень "благодарны"), так ещё и логичного в этом ничего не вижу (AllNoteOff это так-то событие Control Change с определёнными параметрами).
И сам MIDI - это прежде всего протокол передачи данных, поэтому строить над ним высокоуровневые абстракции возможно не самая лучшая идея.
Опять же, не могу согласиться. Да, это протокол передачи данных. Но его активно используют музыканты, например, вставляя в DAW. К слову, DAW пары Note On/Off объединяют, внезапно, в ноты в пиано ролле, потому что, как я и говорил, музыканты не работают в терминах MIDI.
Да и большое число пользователей, вопросов и обращений подтверждают, что API библиотеки сделан более или менее правильно. Библиотека ведь не запрещает вам использовать и "сырые" MIDI-события. Архитектура DryWetMIDI слоистая, есть и слой с абстракциями в терминах MIDI, можно и ими пользоваться. А можно и более высокоуровневыми.
Возможно, более лучшей идеей будет строить высокоуровневые абстракции над более понятными музыканту вещами, такими как классическая нотная запись, пиано-ролл, гитарные табы/аккорды и пр., а MIDI оставить как вариант импорта/экспорта.
Ну так чтобы сделать импорт, понадобится вся та кухня, что есть сейчас по работе с MIDI. Мне кажется, вы полагаете, что библиотека предоставляет только абстракции высокого уровня. Это не так. Даже в README проекта я об этом явно говорю:
DryWetMIDI is the .NET library to work with MIDI data and MIDI devices. It allows:
...
Manage content of a MIDI file either with low-level objects, like event, or high-level ones, like note (read the High-level data managing section of the library docs).
Номер ноты и скорость нажатия лишь примеры, в MIDI намного больше таких сущностей.
Ну и enum не спасёт в случае вычисления значения по какой-то формуле. Придётся результат приводить к этому enum'у. А что если результат есть число, не принадлежащее перечисление? C# всё равно выполнит приведение, есть у enum'ов такая особенность. И пойдёт гулять по программе невалидное значение.
Сам был удивлён, сколько людей мыслят в духе "Мне это не нужно, есть обходные варианты, значит фича ненужная!". И одно дело просто предложить другие способы на подумать, но нет, именно ультимативно заявляется, что идея неверная.
При этом сколько уже было сказано, что функционал нужен не только программистам (это и в статье есть). А даже если и программистам, то не все проекты хочется публиковать (пусть и в приватные репы) на GitHub. Если я подключу второй компьютер и захочу поиметь все эти мелкие квазипроекты на нём, мне на всё репы заводить и git clone вызывать? Действительно, удобно.
Ну да. Есть папка на компьютере, которая синхронизируется с облаком. Но локально у меня ничего не удаляется. Отключусь от облака — локально всё на месте будет.
Да, я тоже PowerShell-скрипт сделал и вызываю при необходимости. Но да, встроенное решение было бы лучше.
Выше написал комментарий, повторю:
Кстати, забавно, что именно самые крупные сервисы облачного хранения не реализуют данную фичу: Dropbox, Google, Microsoft. Хотя реализация данной штуки, хоть, возможно, и не значительно, но была бы преимуществом перед конкурентами.
Наезд на Dropbox связан с наличием портала, куда пользователи могут публиковать идеи, с наличием самой запрашиваемой фичи и с откровенным безразличием к такой идее со стороны компании в течение 10 лет.
Ну, например, в MEGA сделали именно то, что требуется: https://help.mega.io/ru/installs-apps/desktop/megaignore
В Koofr тоже: https://koofr.eu/blog/posts/advanced-ways-to-exclude-files-from-sync-part-2
Есть зачаточное решение у pCloud: https://www.pcloud.com/help/drive-help-center/how-do-i-exclude-files-or-folders-from-my-backup-sync-or-ongoing-transfers-in-uploads
Вы всё верно пишите, что не стоит ждать у моря погоды. Я уже и не жду, я у себя сделал примитивное решение в виде PowerShell-скрипта, который нужно запускать. Но мне кажется неверным видеть что-то неудобное и просто молча делать костыли с мыслями "Ну ладно". Всё же встроенное решение есть самый правильный путь, Мечты...
А оффлайновый бэкап всегда есть локально на компьютере. Хотя Dropbox позволяет включать режим online-only для сохранения места на диске (и некоторые им пользуются), я всё храню автономно на своём компьютере.
Да, нужна поддержка в клиенте. Ну и на сервере по части особой работы с файлом .dbignore (или как его назовут). Про создание сторонних клиентов не подскажу, были такие сообщения в дискуссиях, но я не заметил, чтобы в итоге кто-то счёл это реальным, нужно изучить.
Сложно поверить, что их CEO до сих пор не знает о таком фича реквесте :-) Но я понял, о чём вы говорите касательно недостатка внимания к порталу с пользовательскими инициативами. И для большинства идей такое вполне может быть. Но не для самой запрашиваемой, и не 10 лет.
Про сложности реализации возможно. Хотя это и удивительно (но бывает), что такая крупная компания не может за всё это время реорганизовать код. В принципе это тоже что-то говорит о продукте и управлении им.
MEGA молодцы, они сделали именно то, что нужно: https://help.mega.io/ru/installs-apps/desktop/megaignore
Т.е. они позволяют создать специальный файл .megaignore и указать паттерны для исключения. И эта компания не посчитала, как некоторые в комментариях, что это ненужный функционал. Причём сделали они его даже без громких возгласов аудитории.
Считаю пример с посудомойкой совершенно некорректным. Сервисы по облачному хранению данных оперируют файлами, поэтому вполне легитимно просить от них неких "улучшений" этих самых операций по обработке файлов. А отсеивать ненужные файлы (пользователь сам решит, что нужно, а что нет), как по мне, само собой напрашивается.
Но, разумеется, ваше мнение может не сходиться с мнением тысячи людей, желающих эту "высосанную из пальца" фичу.
Да, такие решения фигурировали в обсуждениях идеи. Но, как мы все понимаем, это костыли, и официальное встроенное решение было бы лучше.
Но ведь я про версионирование вообще не говорил. Лично я важные проекты, разумеется, веду в GitHub. Но ничего не должно мне запрещать хранить эти проекты ещё и в Dropbox. Вообще в статье целый абзац есть касательно того, о чём вы говорите. Но пару моментов повторю:
У меня много утилит, которые я делаю просто, чтобы разово что-то проверить или сгенерировать. Я не хочу класть их в GitHub, создавать репозиторий, выполнять какие-то команды. Мне нужен просто бэкап этих проектов, чтобы я мог на другом компьютере их сразу же поиметь при синхронизации с облаком и всё.
Обсуждаемая в статье фича нужна не только программистам (в статье про это написано).
А как оно устроено у меня, можно почитать в статье Создание .NET библиотеки от А до Я. Там и GitHub и пайплайны и релизы и документация и чего только нет. Только это не должно мне запрещать использовать Dropbox простым способом: хранить там проект и не отправлять временные файлы в облако.
Dropbox для хранения файлов. Исходники тоже файлы.
Более того, даже в рамках дискуссии по обсуждаемой идее компания довольно быстро признала, что возможность исключать файлы из синхронизации людям нужна. В статье всё это написано. Написано даже, что нужно это не только программистам с их злополучными исходниками.
Есть опыт других компаний, которые возможность игнорирования файлов предоставляют. И никто мозги ложечкой им не ест.
Я уже не говорю о том, что (повторяю написанное в статье) Dropbox сам предоставил площадку для публикации идей и вот у них на руках самая желаемая фича, и они её игнорируют.
Слишком категоричное заявление. Из моего опыта обращений пользователей это не так. Хотя, подтверждаю, задача одна из популярных.
Совершенно верно, и VSTi это уже про генерацию аудио (собственно, звука). VSTi забирает данные из MIDI Input и генерирует звук. MIDI это только про команды для синтезатора (аппратного, программного, VSTi и иже с ними), MIDI абсолютно никак с генерацией звука не связан сам по себе.
Думаю, ваша проблема была какой-то иной или я чего-то не понял. Что мешает озвучивать ваш синтезатор (аппаратный, как я понимаю, речь не про генерацию MIDI из программы) любым VSTi? Зачем тут какой-то "низкоуровневый звук"?
Если же речь про озвучивание генерируемого программой MIDI, то ситуация стандартная и решается не менее стандартно через виртуальные устройства. Как я и писал выше, virtual cables это называется. Из наиболее популярных и бесплатных, наверное, loopMIDI:
создаёте в loopMIDI устройство с именем X;
выводите MIDI плейбек на этот X;
забираете данные из X в любом нужном вам VSTi (т.е. у инструмента указываете MIDI Input = X).
Хорошее замечание, спасибо.
Принимаю. Но для пользователей функция, от того алгоритма зависящаая, работает верно.
Вы путаете MIDI и Audio. MIDI playback никогда не будет без таймера. Audio будет, звук выводится на аудио-устройства посредством буфера.
Любой VSTi имеет параметр MIDI input. Это MIDI-устройство, откуда принимать даные. Стандартная практика вывода программного MIDI в VST-инструмент — виртуальные устройства (aka virtual cables). DryWetMIDI предоставляет возможность выводить MIDI.
Процент задач, в которых нужно вникать в низкоуровневую реализацию намного меньше прикладных задач, в которых получить ноты или выполнить их квантизацию есть насущные проблемы.
Разумеется, каждый сам выбирает себе инструмент, который ему больше нравится.
Возвращаясь в русло статьи: в обеих этих библиотеках нет предлагаемого вами подхода — каждый класс класть в отдельное пространство имён. Повторюсь, вы первый, кто такое практикует. Это любопытно, и в любом случае спасибо за комментарий.
Я за критику, но конструктивную. В прошлой статье были комментарии, указывающие на минусы подхода с кастомными структурами. Очень благодарен этим замечаниям, я их добавил в статью даже.
Да, об этом сказано в статье:
По поводу
не согласен категорически. Мало того, что я вообще в первый раз вижу отдельные пространства имён под каждый класс (пользователи за это будут вам очень "благодарны"), так ещё и логичного в этом ничего не вижу (AllNoteOff это так-то событие Control Change с определёнными параметрами).
Опять же, не могу согласиться. Да, это протокол передачи данных. Но его активно используют музыканты, например, вставляя в DAW. К слову, DAW пары Note On/Off объединяют, внезапно, в ноты в пиано ролле, потому что, как я и говорил, музыканты не работают в терминах MIDI.
Да и большое число пользователей, вопросов и обращений подтверждают, что API библиотеки сделан более или менее правильно. Библиотека ведь не запрещает вам использовать и "сырые" MIDI-события. Архитектура DryWetMIDI слоистая, есть и слой с абстракциями в терминах MIDI, можно и ими пользоваться. А можно и более высокоуровневыми.
Ну так чтобы сделать импорт, понадобится вся та кухня, что есть сейчас по работе с MIDI. Мне кажется, вы полагаете, что библиотека предоставляет только абстракции высокого уровня. Это не так. Даже в README проекта я об этом явно говорю:
Спасибо большое за полезный комментарий, добавил информацию в статью.
Да, соглашусь.
Вообще, в библиотеке касательно вашего подхода есть несколько методов, например:
или
Длиннее, чем
enum, но идея та же, и она верная: по имени ноты и октаве получить ноту/её номер.Номер ноты и скорость нажатия лишь примеры, в MIDI намного больше таких сущностей.
Ну и
enumне спасёт в случае вычисления значения по какой-то формуле. Придётся результат приводить к этомуenum'у. А что если результат есть число, не принадлежащее перечисление? C# всё равно выполнит приведение, есть уenum'ов такая особенность. И пойдёт гулять по программе невалидное значение.