semitones & cents

[Bulba]

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

Да, похоже. Но возможно, указание в треке огибающих конкретного номера канала все-таки избыточно. Сэмпл огибающей только с одной маской "on/off" ну плюс как-то тип может в этот же сэмпл загнать. А о том, в какой конкретно канал мешать - это уже в самом треке канала указавать, и мне кажется, что не пометкой в треке, а той же маской, но уже в сэмпле канала. Тогда в сэмпле канала тип огибающей уже не нужен.

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

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

Зато это более наглядно, в отличие от того же ASC и PSC - всегда видно с каким именно шумом в данной строке работаем, не нужно помнить, что где-то раньше шум был смещен.

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

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

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

Я в своем формате предусматривал спец. комманду в откомпилированном блоке

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

важно в какой части диапазона) будут дублироваться. Думается мне что при такой раскладке архивация AY-потока даст существенный проигрыш.

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

Просто реализуете свой AY формат на спекки. Кстати, может быть AY плеер на спектруме есть?

Есть, на моем сайте есть ссылка. Блин, забыл про обещание добавить там ссылку на сайт Bugsy, постараюсь скоро исправиться

... Ay_Emul: Silent now...