semitones & cents

[Shiru]

По скриншотам вряд-ли что-то будет понятно. Вот, скрин редактора всей композиции (song_editor). Каждый кубик - это риф (одна клетка = 16 нот). Риф - это одноголосая мелодия (типа одного канала в трекере), может быть набрана любыми инструментами, каждой ноте может быть назначен персональный эффект. См. скрин riff_editor. Конечно, там дофига графики, ориентация на джойстик, и куча упрощений (всё-таки, это для обычных юзеров, а не музыкантов программа), но это всё можно выкинуть, доработать, и переработать. Спек потянет. Кстати, по-моему, был порт этой проги для PC.

midi - да, без паттернов (btw, Clip в Cakewalk - это нечто типа riff'а в Music). Только выходной файл - сродни потоку значений для регистров AY, а это для ZX неприемлимо.

[Advertiser]

[SMT]

дык это ж бубль гум! (в смысле, fruity loops )

[Dexus]

дык это ж бубль гум!

Ну вообще это очень упрощеный для казуалов вариант любого более-менее цивильного секвенсора (как например тот же Cakewalk/SonarXL)
Высота ноты отображается реальной высотой в "таблице". Эффекты - в скролле снизу.
Основной минус подобной раскладки - это невозможность увидеть все и подробно (ну или хотя бы многое). Обычно можно редактировать 1 канал. Но при этом есть возможность "масштабировать" канал, т.е. видеть и 1/16 и 1/32 и 1/64 нотки (которыши). Но вообще я сомневаюсь что этот вариант пойдет для спектрумовой дискретностью в 1/50 секунды и ограниченностью в 3 канала.
Если даже предложить возможность раскидывания нот с точностью до 1/50 секунды, то каким макаром менять темп потом, если вдруг он оказался малость не такой как хочется? на коэффицент домножать? Тогда получится чопопало.

Хотя я думал уже о том, чтобы была возможность устанавливать плавающий темп. Например чередуются 6 и 5 тактов... в среднем получается 5.5. или 6,7,6 - получается 6,33 (своего рода алгоритм брезенхема для длительностей). Но это не с точностью до такта. Это все равно ориентир на темп (длительность одного музыкального такта), а позицировать ноты уже в "координатах" такта. Но как тогда понять какой из тактов будет короче а какой длиннее? Программа сама как захочет так и расставит. А неуместный сдвиг в 1/50 секунды время от времени будет достаточно заметен.
В конце концов AY + 1/50 для секвенсирования мягко говоря не очень подходит.

Вот что я точно хочу видеть в трекере - это возможность "раздробить" какой-то такт. Т.е. чтобы не было ограничения в 64 строчки на "паттерн". Было бы неплохо если бы номера были не совсем "строк", а нот, с учетом оригинального темпа и дробления, т.е. допустим идет 0, 1, 2, 3, 4, 4.3, 5, 6, 6.3, 7 (.3 означает 3 прерывания после целого). Дробные "десятичные" доли тут не вполне пойдут по вполне понятным причинам.

Все-таки по-моему от "трекерной" технологии убегать далеко не следует.

[Bulba]

Сделать 'риффы' - последовательность нот/команд для одного трека, произвольной длины

Это как раз концепция FXM - там так и сделано.

[Bulba]

Собстстваенно за день, я так и не услышал конкретных предложений по будущему трекеру (все свелось к обсуждению моих спонтанных мыслей). Видимо придется принимать волевое решение и делать все по-своему. С другой стороны, не я был автором идеи прийти к единому мнению

... Ay_Emul: Silent now...

[Dexus]

Собстстваенно за день, я так и не услышал конкретных предложений по буудщему трекеру (все свелось к обсуждению моих спонтанных мыслей).

Ну во-первых - конкретные предложения _впринципе_ могут появиться только после достаточно активного обсуждения _любых_ мыслей (в том числе и спонтанных).
Во-вторых, в рамках форума обсуждение _активным_ быть не может. Тут же не ICQ и не IRC, точки соприкосновения находятся медленно. Много чего из посланий упускается. Вот я, например, много всяких мыслей своих выдвинул. Ширу тоже выдвинул предложение "секвенсорного" типа (а не трекерного). Мало что было замечено, и еще меньше "обсуждено".

Все вразброд. Друг друга почти никто не слушает. В результате кто-то вообще спасует, кто-то начнет делать _свое_ без учета других мнений, и в результате рискует получить что-то неудобоваримое.

А идея исходить лишь из "возможностей редактора" но никак не с точки зрения реализации кода может привести к тому, что код плеера будет занимать половину или даже больше процессорного времени.

По-идее обсуждать это надо в онлайне а не через "форум".

[Bulba]

трек огибающей (либо нота, либо делитель, плюс тип огибающей, плюс имаджи и сэмплы(сдвиги делителей),

Для типа огибающей есть более интересное предложение (впервые услышал от AlCo года три назад) - загнать тип в сэмпл (или в masker по моей терминологии). Если в сэмле будет возможность чередовать тип огибающей E и C например, то упростится реализация соответсвующего давно известного приема, который пока делается в треках за счет подбора нужного tempo.

[Bulba]

То что формат должен быть "гибким" (3 и 6 каналов) - с этим не спорю. там одним байтиком различаться, допустим. Единственное что можно будет сделать 1чиповому челу с 6тиканальной мелодией - это прослушать раздельно 1 половинку и 2ю.

Либо воспользоваться гибконастраиваемым (в realtime) алгоритмом "6 в 3" - напрасно Вы отрицаете эту возможность, которую можно сделать и вне трекера/стандартного плеера (например, в виде плагина к ZX Amp).

[Bulba]

А идея исходить лишь из "возможностей редактора" но никак не с точки зрения реализации кода может привести к тому, что код плеера будет занимать половину или даже больше процессорного времени.

А идею проигрывать массив регистров Вы уже отвергли? И напрасно. Во-первых, во многих демках это уже давно практикуется, ничего более быстрого еще никто не придумал. А когда скорость не важна, достаточно только одного критерия - уложиться в прерывание.

Я это к чему? А к тому, что о программной реализации на этой стадии лучше не думать, у нас и так достаточно трекеров, заточенных исключтельно под кодеров, пора и о запросах музыкантов подумать.

По-идее обсуждать это надо в онлайне а не через "форум".

Я предпочитаю e-mail.

... Ay_Emul: Mm<M oF Sg 21.Feb.99 time 23.47 - tRaCk: NoStalgia iN My Soul !!!

[Dexus]

то упростится реализация соответсвующего давно известного приема, который пока делается в треках за счет подбора нужного tempo

Насколько я знаю, при изменении типа огибающей происходит переинициализация счётчиков (волна заново начинается). Это очень некрасиво будет выглядеть - как сплошная череда щелчков (если будет черезтактовая смена).
А вообще мысль-то конечно интересная.
Но как всегда вплывает куча всяких "но". Например - в обычных семплах (которые без огибающей расчитывается делать) - так же надо указывать? В сэмплах будет холостой "байт"?.
Вообще, если сделать 2 вида сэмплов, тональные и "огибающие", тогда вполне можно.
Но все равно остаётся вопрос с переинициализацией волны. Щелчки неприятны.
Если бы можно было бы сменить форму огибающей без переинициализации волны - тогда было бы круто (Но это вообще тяжело себе представить, потому что далеко не все волны можно состыковать). Мириться с щелчками?