Обсуждение

В архиве: 13 комментариев.

Читать и комментировать в ЖЖ ↗

father_gorry · 30 сентября 2003

Комментарий

Что касается нотной части (миди, все морфинги, контроллеры и т.д.), в новом Ониксе все это реализовано в гораздо большей функциональности, чем этот товарищ пишет. http://www.jasminemusic.net/onyx20.htm А аудиочасть никто не мешает навесить - через миди роутер и Сонар, например.

Анатолий Левенчук · 1 октября 2003

Комментарий

Категорически не соглашусь -- этот вышедший совсем недавно Onix 2.0 нам вполне известен, как и множество других подобных программ (кроме этих "международных новосибирцев" подобными подходами к музыкальному рендерингу занимаются в Ростове-на-Дону: продукты www.musiclab.com устроены внутри гораздо хитрее, нежели написано в их рекламках. Сходите на www.keyguitar.ru -- это их же сайт). Но не нужно путать предложенное нами устройство с вполне реальными knob и sliders, на котором играют realtime, и компьютерную программу, на которой ваяют миди-файл. В нашем варианте вычисляется в real-time непосредственно звук, а не потихоньку (да еще с забеганием вперед, многопроходно) компилируется миди-файл, который потом будет рендериться каким-нибудь миди-плейером. То есть основная разница -- это базовая разница между performance подходом автоаккомпанемента и подходом (как я его назвал в своей уже более чем годичной давности серии статей --- http://www.livejournal.com/users/ailev/1533.html) студийного музыкоделания, подготовки миди-файлов. Морфинг стилей я имел ввиду примерно такой, как в Roland VA-76 -- хотя и немного по-другому реализованный. Да еще с рендерингом и карма-функцией на всех партиях...

Ответ на комментарий

father_gorry · 1 октября 2003

Комментарий

Knob и sliders сейчас можно делать и в компьютере. На рынке есть масса устройств от супербага до кубейсового контроллера, которые завязывают те же самые Knob и sliders на органы управления программы. А карма-функция (если я правильно понял, это предугадывание?) принципиально не справляется с рядом ключевых действий, как то: произвольный sequence|envelope stretch, анализ тональности (только после нескольких тактов игры он может получиться, да и то неуверенно, если это начало партии) и т.д. То есть, любой реалтаймовый автоарранжировщик - это всегда некий ограниченный набор ветвей функций миди-рендерера, да еще и работающий с запаздыванием. Проще говоря, для работы с ним нужно предварительно задать тональность, стили и кроссфейды между стилями (морфинг), что фактически переводит его в разряд миди-рендереров. С другой стороны, приделав к тому же Ониксу внешние железячные контролы и ввод миди-потока в реальном времени, можно получить такого же типа реакцию с тем жезапаздыванием - нулевым, если используется ввод с ручек и в несколько тактов, если ему вменить в обязанность анализ исполнительской манеры на лету. Таким образом, получаем, что с развитием технологий автоарранжировки исчезнет принципиальная разница между миди-рендерингом и реалтаймовой автоарранжировкой. Сейчас в ряде железных синтезаторов есть псевдореалтаймовые стили (хотя таким же образом можно играть и с BiaB), есть обратная связь (кстати, она есть и в софте - Cakewalk In Concert, к примеру), есть преобразование голоса (но Melodyne все равно круче:)) а в Onyx есть самый крутой на данный момент морфинг, гибкие арранжерные и перформансные стили (с поддержкой железа, кстати). Вопрос в том, когда все это дело проинтегрируется. Я все-таки считаю, что дело за софтом. Морфинг в Roland'е на порядок хуже по возможностям, чем в Jammer'e. Стилевые базы Yamaha очень ограничены и защищены копирайтом, тогда как Onyx создает стили из любого миди-файла. Производителям софта не хватает только опыта и зачастую здравого смысла, увы, чтобы сделать функции достаточно понятными - иной раз даже музыкальные обозреватели или профи-арранжировщики не способны разобраться в их программах.

Ответ на комментарий

father_gorry · 1 октября 2003

Комментарий

Сорри, не понял про карму. Да, если это комбинация обучения с управлением, тогда - очень хорошо и переспективно. С другой стороны, что сложного в том, чтобы сделать из wintel'a быстрый миди-хост? Насколько я знаю, сейчас midi-интерфейс работает без задержек, а если его пускать под DX>8, то и любые внутренние задержки исчезнут..

Ответ на комментарий

Анатолий Левенчук · 2 октября 2003

Комментарий

Карма -- это подход www.karma-lab.com Я имею ввиду не конкретно именно эту технологию вариативного комбинирования инвариантов музыкального восприятия (забавный получился каламбур: инвариант восприятия -- это по терминологии Джеймсу Гибсону, тут это -- ступени, гармония, мелодия, ритм и т.д., а вариативное комбинирование -- это изменение такое, чтобы остался как раз какой-то инвариант этого восприятия, например, варьирование ритма такое, чтобы оригинальный ритм все время был узнаваем, или варьирование звуков в арпеджио, чтобы исходное арпеджио в какой-то мере сохранялось). Меня устроит любая подобная по мощности технология. Карма-технология существует сейчас "в хардвере" (это Корг Карма), и в софте -- (это программа к Корг Тритон). Карма-технология позволяет менять звук непосредственно во время перформанса, варьируя до 200 параметров. У меня в тексте ничего на тему "быстрого миди-хоста", и даже по поводу того, на wintel или QNX или еще чем-нибудь эдаком такой хост будет устроен. Тем более, что кроме миди-хоста нужно быть еще и VSTi-хостом, а еще и разные эффекты и внешние звуки хостить (типа Rewire). Я пока ничего не говорю про технологию изготовления. Когда поймем, что изготавливать, можно будет подобрать технологию. А пока непонятен сам предмет: спецификация, пользователские свойства для исполнителя.

Ответ на комментарий

Анатолий Левенчук · 2 октября 2003

Комментарий

> Таким образом, получаем, что с развитием технологий автоарранжировки исчезнет принципиальная разница между миди-рендерингом и реалтаймовой автоарранжировкой. Я ровно об этом пишу. Только опыт показывает, что придется решить множество теоретических задач (рендеринг принципиально двухпроходная технология, а автоаранжировка -- однопроходная, я не беру в учет той разницы, что стиль отрендерен заранее. Стили как раз отлаживаются на предмет "отсутствия неожиданностей" при переключении их вариантов, смене тональности и т.д. Ежели они начнут рендериться "на лету", то об этой тщательной отладке придется забыть, и заново разрабатывать теорию собственно того, что такое стиль. Это будет другая теория, нежели используемая при двухпроходном рендеринге.

Ответ на комментарий

father_gorry · 3 октября 2003

Комментарий

Значит, мы говорили об одном и том же (то, что я залез в практику - привычка такая, уж извольте:)). Но вернемся к реалтайму. По сути, его нет и никогда не было. Прежде чем сыграть песню, ансамбль долго-долго репетирует одно и то же. То же самое касается и джазовых импровизаций - ведь настоящей генерации там тоже нет. Значит, для реалтймовой работы остается только нюансировка - например, нейросеть для сбора информации и нейросеть по принципу "нравится-не_нравится" для обучения программы. А весь остальной (огромный) объем работы - шаблонизация, гармонизация, паттерны - переходит в оффлайн, как сейчас, кстати, везде и сделано. Таким образом, на вопрос, может ли сейчас компьютер заменит живой ансамбль - отвечаем - да, если приделать нюансировку. Те же ониксовые PM-стили, если к ним приделать более удобный ручки и увязать с темпом, вполне для этого годятся. Ну а теперь по поводу сочинения в реальном времени - когда все процедуры должны выполняться на лету. Я думаю, что на это просто не хватит ресурсов человеческого мозга.

Ответ на комментарий

father_gorry · 3 октября 2003

Комментарий

А можно еще раз эти задачи перечислить (Не то, чтобы мне было лень Ваши статьи перечитывать - просто не уверен, что выберу их точно и не добавлю чего-нибудь от себя)?

Ответ на комментарий

Анатолий Левенчук · 3 октября 2003

Комментарий

"Нюансировку" можно трактовать очень широко. Изменение гармонической схемы по ходу дела -- это "нюансировка"? Или это сама игра? Этот этап в компьютинге давно прошли: там введено понятие "виртуальной машины", а потом рассматривается иерархия "виртуальных машин". Так и тут, музыка -- это результат каких-то вычислений, и можно построить иерархию этих частичных вычислений ("прекомпилированных" кусков стилей и т.д.). Конечно, граница между риал-таймом и временем компиляции есть -- но она не такая жесткая, как вы предполагаете. И я не понял еще, когда у нас наступил переход к нейросетям (они-то тут причем? Одна из многочисленных нефон-неймановских архитектур. Могу предложить на выбор еще десяток ;). И уж совсем не понял, причем тут человеческий мозг, который вообще не компьютер, и поэтому его ресурсы мы тут можем не обсуждать (даже не касаясь тех теорий, что основные вычисления у людей ведутся не в мозге, а где-то гм... вне тела... Да и вообще, лучше говорить не "мозг", а субстрат -- отелесненное вне/под/безсознательное, мы так говорим в openmeta). Тут нужно помедленнее, я не всегда успеваю отследить, когда меняется предмет обсуждения и от постановки задачи мы переходим к частным особенностям конкретной реализации :)

Ответ на комментарий

Анатолий Левенчук · 3 октября 2003

Комментарий

А я в статьях своих на эти специальные темы не так много писал -- поэтому мне нужно специально сосредочиться и выделить на это значительную часть времени на описание. Фактически, все сводится к тому, чтобы перемоделировать понятие музыкального стиля (ни больше, ни меньше, со всеми неоднозначностями определения того, что такое "морфинг" в данном случае) и тщательно определить отличия музыкального performance и того, что я называю студийным музыкодельством с точки зрения управляющих воздействий музыканта (или их группы в общем случае). Для этого мы должны определить инструмент как виртуальную машину, исполняющую музыкальную программу, у которой возможны множество режимов работы: музыкодельство (программа скомпилирована, и только воспроизводится), чистый performance (программы нет, все управляющие воздействия отрабатываются "аппаратно", типа как программа редактора отрабатывает нажатия клавиш-стрелочек для перемещения курсора -- назовем этот режим, следуя некоторой программистской традиции, режимом "непосредственного исполнения"), и режим интерпретации (выполнения согласно управляющим воздействиям некоторых прекомпилированных кусков кода, что-то типа запуска интерактивных "скриптов"). Далее требуется определить, каким образом должна быть устроена вычислительная среда, чтобы максимально использовать частичные вычисления (а также мемоизацию -- запоминание таких частичных вычислений, чтобы их не повторять больше). То есть нужно просто перейти с музыкального языка, где нет необходимых для обсуждения понятий на такой язык, где все эти понятия есть. Обсуждать архитектуру "стилевого компьютера", его систему команд, устройство памяти, как архитектурно устроена его связь с внешним миром (ввод-вывод) и т.д. А затем программно отмоделировать получившуюся архитектуру (может быть, даже использовав какие-то готовые программы в качестве строительных блоков).

Ответ на комментарий

father_gorry · 6 ноября 2003

Комментарий

Именно так. (извиняюсь за задержку) Думаю, здесь важно в первую очередь исследование перформанса - точнее, определение того, где находятся общие границы возможностей перформанса _нетренированного_ музыканта. Это если мы хотим делать хоть немного массовый продукт, поскольку инструмент-подобный интерфейс (скажем, для скрипки) нереально сделать работающим именно так, как эта скрипка. И почему-то мне кажется, что результатом исследования будут понятия, описывающие миди-клавиатуру, одно-два колеса и кнопки для выбора мемоизаций:))) И не более того. А все более сложные алгоритмы все равно останутся в области "студийного музыкодельства". То есть музыкант всегда предпочтет(по причине ли удобства, или трудности обратного) делать как можно больше в многопроходном режиме, а на импровизацию оставлять минимум.

Ответ на комментарий

Анатолий Левенчук · 6 ноября 2003

Комментарий

Ну, это вечный вопрос: для кого делаем :) Ответы дают всякие "цифровые фотоаппараты": в пределе все функции у него автоматизированы, но любую функцию можно перевести на "ручное управление". Понятно, что сделать можно инструмент с "кнопками мемоизации", каждую из которых можно программировать -- да еще и на разных уровнях. В любом случае, вопрос в языке программирования (вот, в Карма-станции используется некоторое программирование, и оно кажется музыкантам очень сложным). А язык программирования можно сделать общемузыкальным, а можно стиль-зависимым (так, в латинских ритмах вводить дескаргу, а в маршах -- трио как части пьесы). Хуже с такими стилями, которых еще нет. Но они могут вполне программироваться на языке описания стилей. Вот это бы и создать ;) Увы, сейчас времени на это нет -- зыбкость определения стилей хорошо видна сейчас на примере электронной музыки, где какой-нибудь джангл и даб весьма неформально связаны с брейкбитами...

Ответ на комментарий