semitones & cents

[Dexus]

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

Во-первых, куча AY регистров будет весить в памяти просто немерянно.
Во-вторых, в демках процессор еще и для самой демки нужен, кроме самой музыки-то. А если больше половины прерывания займет плеер, тогда на графику ничего не останется. Нафиг такое пошлют.

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

А я о запросах "музыкантов" не думаю? (Правильнее сказат - композеров). Я свой PSM начал писать только по той причине что трэкеры которые были у меня (ST и ASC) - не очень удобны. СТ - вполне юзабелен, но под "хорошую" музыку очень слабо заточен. Слабоват (ни громкостей, ни разных длин паттернов даже). АСЦ - достаточно мощный, но совершенно неудобен и неюзабелен. Не надо обо мне думать как о "кодере", ничего не смыслящем в музыке. Я хоть и муз. образования не получал, но слуха не лишён. На PC писал музыку (не трекерную). И вполне представляю себе что необходимо композеру для более успешного воплощения задумок, и что можно сделать по этому поводу с точки зрения кода, и что - не очень.

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

Тогда скорее всего активного (оперативного) обсуждения не получится. Ширу обещался выйти на меня - что-то не видно. А сидеть тут в форуме "сторожить" через 5 минут тыкая F5 - не очень прикольно.

[Bulba]

Насколько я знаю, при изменении типа огибающей происходит переинициализация счётчиков

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

[Bulba]

Во-первых, куча AY регистров будет весить в памяти просто немерянно.

Не люблю я пустых утверждений - столь быстрый ответ на мое предложение говорит не сколько об оперативности обсуждения, сколько о том, что Вы даже не попытались провести соответвующие эксперименты. Именно потому идею online обсуждения я и отвергаю. Любую мысль прежде, чем поддержать или опровергнуть надо тщательно взвесить, иначе все превртится в болтологию. Я эксперементы по сравнению размеров компилированных модулей и сжатых разными методами массивов регистров проводил, иначе бы не предлагал.

Во-вторых, в демках процессор еще и для самой демки нужен, кроме самой музыки-то.

Я же уже написал - для демок можно использовать массив регистров, для простого прослушивания в каком-либо плеере достаточно уложиться в int плюс небольшой запас под визуализацию. В демках даже очень быстрые STP/PT2-плеера не всегда можно воткнуть, а интерпретатора шестиканального модуля более быстрого все равно не написать.

А если больше половины прерывания займет плеер, тогда на графику ничего не останется. Нафиг такое пошлют.

Не пошлют. Даже моему универсальному плееру PT3 нашлось применение в ZX softe (хотя он раза 2-3 медленнее стандартного). QC, RC, AToy2005. А демка - это в любом случае уникальный продукт, там можно и повозиться со встраиванием музыки, если действительно есть желание удивить публику.

А сидеть тут в форуме "сторожить" через 5 минут тыкая F5 - не очень прикольно.

И не надо - ответы раз в сутки вполне для меня оптимальны - я к пограммированию трекера в ближайшие месяца два все равно не приступлю. А потом перечитаю весь тред и начну кодить

... Ay_Emul: Silent now...

[Dexus]

Ладно. Это не суть. Вопрос в другом - канал "огибающей" сам по себе и не канал вовсе. Он не может выводиться не трогая A/B/C. Как можно "раскидывать" его по каналам? Или так же, внутри "сэмпла огибающей" делать маркировки влияния на каналы? Или для каждой ноты в канале огибающей рисовать "распределение" по каналам? Или внутри обычных сэмплов иметь тот же флажок E, который будет врубать огибающую в данном канале (если она включена).
Вот этот вопрос для меня точно остается неясным..

[Dexus]

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

Эксперементы в написании музыки методом poke?
Нет уж, увольте. Ибо абсурд.
Написание музыки, это не процесс механического занесения циферок-буковок, а 130% интерактивный процесс, как можно более упрощеный и комфортабельный.
Я не спорю что можно "разложить" музыкальный поток AY регистров, и запаковать его. Но это уже ближе к стадии "компиляции", если уж на то пошло. Кроме того, 6тиканальный поток будет занимать в 2 раза больше. Не смотря на то что "сэмплы" во втором экземпляре абсолютно те же.

Не.. подобную идею я для личной безопасности даже рассматривать не буду Хватит. Мне хватило уже написания мелодий командой PLAY ""

Но вообще, сам формат потоковый (команд-операторов в канале откомпилированной мелодии) - фактически аналог миди. Единственное основное отличие - это дискретность пауз (с точностью до текущего темпа).

[Bulba]

Вопрос в другом - канал "огибающей" сам по себе и не канал вовсе. Он не может выводиться не трогая A/B/C. Как можно "раскидывать" его по каналам? Или так же, внутри "сэмпла огибающей" делать маркировки влияния на каналы?

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

Как видите, по Вашему варианту все равно возникает дополнительная структура "сэмпл огибающих". Именно поэтому я и предложил выделить из традиционного сэмпла маски и вибраторы: первые можно указать только в треках каналов, а вторые универсальны для всех генераторов.

Или внутри обычных сэмплов иметь тот же флажок E, который будет врубать огибающую в данном канале (если она включена).

Да, мне кажется, это лучше. Этот флажок будет отвечать за бит огибающих регистра амплитуды. Я чуть выше предложил еще ввести в сэмпл четыре бита типа огибающей (допустим, 0 - тип без изменения, 1-F принудительная переинициализация). Но по большому счету, тип огибающей можно указывать и не в сэмпле, а в треке огибающих, но это более ограничивает возможности, хотя, безусловно, и чем-то упрощает процесс создания сэмплов/эффектов.

[Advertiser]

[Bulba]

Эксперементы в написании музыки методом poke?
Нет уж, увольте. Ибо абсурд.

Какой poke, Вы совсем меня не поняли. Берем любой формат, например PT3, конвертируем его в массив регистров. Подготавливаем (1) и пакуем (2) массив так, что бы можно было находу быстро распаковывая выбрасывать в регистры AY. Понятно, что на шаге (1) и (2) множество вариантов - вот с этим я Вам и предлагал поэксперементировать. Размер пакованного блока _сравним_ с размером компилированного PT3 (плюс минус пара килобайт в зависимости от конкретного модуля).

[Lounge Lizard]

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

... Ay_Emul: Silent now...

Ну я предложил инструменты сделать, чтобы это было похоже на нормальные трекеры как на Amiga или на PC. Это будет в любом случае удобно, безотносительно формата файлов, одного или двух AY и всего остального, что сейчас тут обсуждается.

[Bulba]

Ну я предложил инструменты сделать

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

[Dexus]

Я чуть выше предложил еще ввести в сэмпл четыре бита типа огибающей (допустим, 0 - тип без изменения, 1-F принудительная переинициализация). Но по большому счету, тип огибающей можно указывать и не в сэмпле, а в треке огибающих, но это более ограничивает возможности, хотя, безусловно, и чем-то упрощает процесс создания сэмплов/эффектов.

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

Насчет канала шумов - мне не очень понравилось что в PT3 в каждой строке нужно указывать текущую "глобальную базу шума". Из-за этого многие ASC мелодии, в которых используется "память" предыдущей базы шума криво импортируются в VTII (Хотя бы та же "TRANTOR.asc").

Размер пакованного блока _сравним_ с размером компилированного PT3 (плюс минус пара килобайт в зависимости от конкретного модуля).

Я в своем формате предусматривал спец. комманду в откомпилированном блоке - что-от вроде use(addr,cnt), "ссылки" на предыдущий фрагмент (без вложенностей). Вкупе с хранинием вместо абсолютных номеров нот - их смещения относительно предыдущей - схожие фрагменты мелодий (не важно в какой части диапазона) будут дублироваться. Думается мне что при такой раскладке архивация AY-потока даст существенный проигрыш.
В любом случае этот метод можно будет использовать "как вариант".
Просто реализуете свой AY формат на спекки. Кстати, может быть AY плеер на спектруме есть?