Снова о плейерах PT 3.x
Alone Coder
В прошлом номере был опубликован сбор─
ник коротких плейеров Сергея Бульбы,но
это не последняя страница в истории PTЗ
плейеров. Я взял плейер от Dr.Lion/RSMи
сделал на его основе настраиваемый плейер,
размер которого в большинстве случаев не
превышает одного килобайта.
* * *
Окунёмся в историю.
Pro Tracker 3 by Nick / Golden Disk
Corporation, появившийся в 1997 году, был
достойным продолжением предыдущих версий
Pro Tracker от того же автора.
Как можно видеть по популярным тогда оп─
росникам в газетах и статистике релизов, в
те славные времена эра 48K компьютеров у
нас как раз заканчивалась, и появившееся
пространство для манёвра казалось бескрай─
ним - 128К, а у многих и больше! (Отечест─
венные Спектрумы, имевшие встроенный из
коробки AY, как правило, имели и больше
памяти, но ей обычно жертвовали ради сов─
местимости, а драйверы для неё только-то─
лько появлялись.) Сам редактор требовал
128K. Да и под музыку предполагалось выде─
лять целую страницу,а не кусок 48K памяти,
что видно по дефолтному адресу компиляции
(#C000) :)
Оригинальный Pro Tracker 3.1a (и 3.31)
имел встроенный компилятор с плейером раз─
мером#E21 байт (3 с половиной килобайта).
Плейер имел типичную структуру с наст─
ройщиком, но его вряд ли предполагалось
использовать с несколькими треками, потому
что из двух имевшихся в редакторе частот─
ных таблиц в плейере каждый раз могла ис─
пользоваться только одна, а при запуске
нового музона плейер инициализировался не
полностью (я обычно обходил это, указывая
в первой ноте трека инструмент, орнамент и
громкость).
Плейер имел критическую ошибку в обра─
ботке командыбxxx (вибрато), но эту кома─
нду мало кто использовал в музыке; также
имелась пара небольших ошибок в команде
Зxxx (портаменто) - одна в компиляторе
(касалась порядка компиляции, чтобы при
переходе портаменто через границу паттер─
нов параметры рассчитывались верно хотя бы
для уникальных паттернов),другая в плейере
(надо было учитывать глисс). По слухам,
редактор писался автором в армии, и после
службы автор уже не возвращался на сцену.
В 1999-2000 годах Sage Group в лице
Mm<M'а и MOnS+eR'а решили облагородить ре─
дактор. Изменения коснулись интерфейса,
количества частотных таблиц (их стало че─
тыре), таблицы громкости и этого самого
плейера. Плейер от Sage Group занял#D86
байт с функционалом, в принципе идентичным
оригинальному.Исходников редактора у ребят
не было. Сам редактор исправлял Mm<M -
прямо по машинному коду. Плейер декомпили─
ровали.
Это был новый этап в развитии плейера -
теперь он распространялся с исходником!
Кроме плейера для самого редактора MOnS+eR
сделал ускоренный плейер для газеты Born
Dead, для которого надо было особым обра─
зом подготавливать музыку.
(В приложении вы можете найти плейер из
Bord Dead #10 -XXXX_I1.H - и утилиту для
подготовки трека -CON_A.H .)
Работа над редактором была завершена в
связи с появлением у Sage Group проекта
Minimal Tracker.
Параллельно в среде издателей электрон─
ных журналов начали появляться решения для
использования одного плейера с двумя час─
тотными таблицами. Основная идея - адрес
таблицы в плейере известен, её можно под─
менять не самим плейером, а внешней прог─
раммой. Такой плейер в своё время делал и
я. Такие плейеры были нужны и в системных
программах.
Я начал адаптировать Pro Tracker в 2001
году, изначально для того, чтобы добавить
поддержку мыши. В итоге я декомпилировал
редактор, выпустил несколько десятков вер─
сий, где исправил ряд проблем (в том числе
ограничения по темпу и длине паттерна),
добавил общим счётом 38 горячих кнопок (ох
как их не хватает в Vortex Tracker'е !) и
множество разных фич, в том числе смену
орнамента без смены огибающей,"прозрачный"
ввод огибающей, копирование с наложением,
"транспозицию" громкости, Merge модуля и
поддержку TurboSound.
По исходнику от Sage Group я сделал два
плейера: "fast" (быстрый, как и оригинал)
и "mic&rc" (короткий, медленный в пике, но
быстрый в среднем). "mic&rc" шёл в систем─
ные программы, "fast" - в остальные. Оба
плейера были существенно короче старых, но
самое главное изменение заключается в том,
что они НАСТРАИВАЮТСЯ, в том числе можно
включить поддержку всех 4 частотных таблиц
одновременно.Командабxxx была исправлена,
в последних версиях была, насколько можно,
исправлена и команда Зxxx. Обе команды
можно и просто выключить в настройках, при
этом плейер становится короче и быстрее.
Было убрано оригинальное ограничение по
темпу. Если темп ниже 3 раньше нельзя было
использовать вообще, то теперь с плейером
"fast" стало можно использовать темп 2, а
с плейером "mic&rc" - и темп 1. Ограниче─
ние было связано с тем, что разбор нотного
текста шёл по одному каналу за фрейм. Мой
плейер "fast" мог при темпе 2 разбирать
два канала сразу. А плейер "mic&rc" разби─
рал сразу все,что освобождало от необходи─
мости перекидывать кучу переменных (поэто─
му в среднем он даже быстрее,чем "fast" ).
Эти новые плейеры были основаны на мак─
росах,что позволяло исправлять код во всех
каналах одновременно. Использование в этих
макросах параметрических меток (особен─
ность ALASM) долгое время не позволяло ко─
мпилировать их в кросс-ассемблерах. К сча─
стью,я недавно смог приручить SjAsmPlus, и
с помощью довольно неуклюжих конструкций
плейер "fast" теперь там компилируется
(ищите в приложении).
Шло время, и в один прекрасный момент
пользователи сказали, что компилятор в ре─
дакторе им не нужен, увеличение памяти под
модуль важнее. Дело в том, что модуль ком─
пилируется в ту же страницу, где лежит код
плейера, и если он выходит за её пределы,
его нельзя правильно выгрузить. Это было
особенно актуально после того, как я уве─
личил число паттернов с 42 до 48.
Чтобы компилировать с удобством,я напи─
сал утилиту PT Util. Кроме компиляции там
есть ещё декомпиляция,сортировка паттернов
и каналов, но самое интересное заключалось
в плейере!
В чём идея? Плейер в PT Util (потомок
mic&rc ) не имеет инициализации. Она дейс─
твительно не нужна,если компилируется пле─
йер под один трек. Нужна всего одна точка
входа - играть один фрейм. Кроме того, в
треке можно хранить не относительные адре─
са, а абсолютные - это экономит и память,
и время. Выигрыш был огромным - плейер за─
нял всего#900 байт.
И тут произошёл новый шаг - в 2004 году
Dr.Lion/RSM со своей стороны и Сергей
Бульба со своей стороны сделали плейеры,
которые не имеют процедуры на каждый ка─
нал, а играют все каналы одним кодом,испо─
льзуя индексные регистры. История не сох─
ранила, как писал плейер Сергей Бульба, но
Dr.Lion сделал плейер на основе "mic&rc",
заменив уже упомянутые параметрические ме─
тки в макросах на обращения к(IY+d).
Плейер Dr.Lion'а не мог похвастаться
обширной документацией и долгое время тихо
лежал в исходниках Pro Tracker'а ... пока
не вернулась пора 48K демомейкинга.
В то время я уже помучился, упаковывая
дему New View 48K с плейером от Сергея
Бульбы (занимает в памяти#86E байт с ука─
занием в инструкции, что код весит всего
#651 ),и решил выяснить: что же мы, собст─
венно, имеем ещё на данный момент,и какие,
собственно, перспективы?
А имеем мы...#бCE байт от скромного
Dr.Lion'а, более чем в два раза короче
оригинала! Я совершенно забыл про этот
плейер, хотя он всё время лежал у меня под
носом. И не просто самый короткий плейер,
но и самый читаемый!
Я лихорадочно сел изучать код,по дороге
перевёл комментарии на английский и заме─
нил числа в(IY+d) на метки. Как всё стало
просто и понятно!
Сократил плейер за счёт заменыiy на hl
в некоторых местах, убрал инициализацию.
Пара сотен байт в кармане. Пошёл дальше.
Добавил настройки на выкидывание команд,
как в моих плейерах. Стал проверять на
коллекции разных треков. Со времён The
Compo я знал, что можно писать без команд
вообще (я сделал выкидывание всех команд)
и без накоплений в сэмплах (так обычно
компилируется музыка в Info Guide ).Заодно
заложил убирание сдвига огибающей в сэмп─
лах (благо некоторые даже не знают, что в
PTЗ такая возможность) и сдвига шума в
паттерне.
А что если отрезать заголовок сонга
(первые 105 байт)? Он же используется то─
лько при инициализации,а плейеру не нужен!
Отрезал. С этого момента длину плейера
считаем как длину блока плейер+модуль, ми─
нус длина оригинального модуля (иначе про─
сто треснет голова).
А что если убрать таблицу громкости?
Ведь можно писать под линейную таблицу!
Pro Tracker компилируется под такую левым
мизинцем (одна такая версия - PTЗ.7Зli,
она лежит в приложении вместе с полным ар─
хивом текстовой документации). Не знаю на─
счёт Vortex Tracker'а - во всяком случае,
хакерскими методами таблица в его теле об─
наруживается (например,в версии1.0 beta18
- с адресаOxBE2A8 ). В общем,сделал и та─
кую настройку.
А что если сократить таблицу частот?
Эммм... Чтобы не париться с пересчётом ча─
стот, сделал обкусывание начала и конца
таблицы - столько нот, сколько хочет юзер.
Приготовьтесь...
#23B байта на тестовом сонге. 571 байт!
Вспоминаются слова одного фидошника,ко─
торый обещал Медноногову загнать музыку из
5 в 2 килобайта,если ему не хватает памяти
- лишь бы он доделал Чёрный Ворон 2 ...
А ведь это не предел - мы же ещё не ме─
няли формат модуля :)
* * *
Напоследок о том, как писать (или обра─
ботать) модуль,чтобы при его использовании
было меньше проблем.
По размеру:
1. Больше всего занимает музыка с чере─
дованием темпа. Чаще всего чередуются два
значения. Во многих случаях этого можно
избежать, если удалить каждую вторую стро─
чку (если там используются паузы, то мож─
но добавить копии инструментов с паузой
или использовать команду vibrate(бxxx) ).
Vortex Tracker не имеет средств для удале─
ния каждой второй строчки,это можно делать
в Pro Tracker (нажатьChannel, потом ss1 и
далее топтатьcsO ). Так удалось "спасти"
трек Moran'а "ZX-HypnoPUNK", который даже
не выгружался из редактора из-за размера.
Можно сэкономить и другим образом - внед─
рив автоматическое переключение темпа в
сам плейер.
2. Одинаковые каналы кодируются один
раз. Если у вас повторяется линия ударных
за исключением конца паттерна, отрежьте
этот конец паттерна во всех случаях в от─
дельный паттерн.
3. Смещения шума прописываются в канале
B. Если вы их используете при одинаковом
содержимом канала B, то будет лишняя копия
этого канала. Можно их вообще не использо─
вать - плейер станет короче и быстрее.
4. Можно экономить на хвостах инструмен─
тов, если эти инструменты реально играются
не до конца.
5. Накопления в инструментах реально ну─
жны только для длинных,зацикленных инстру─
ментов.Если вы отладили звук,можете убрать
накопления. Если число строк в инстру─
менте не поменялось, то это чистый выигрыш
в размере и скорости плейера (настройка
smpfix ).
6. Если огибающая звучит в двух каналах,
то в одном из них можно пропускать тип
огибающей (достаточно прописать его один
раз). При этом и не будет лишний раз хра─
ниться период огибающей (2 байта).
7."F" перед номером орнамента писать не
обязательно (начиная с PTЗ.69 ).Это эконо─
мит один байт на каждую такую ноту.
8. Часто можно экономить на прописывании
громкости (почаще ставитьF ),если соотве─
тствующим образом отредактировать инстру─
менты.
9. Если можете избежать команд по всему
сонгу - сделайте это.Это может значительно
сократить плейер (а в случае глиссов и ви─
брато - и ускорить). В плейере можно выб─
росить каждую отдельную команду или даже
все.
По сложности воспроизведения (такты):
1. В большинстве случаев вопрос стоит о
максимальном времени воспроизведения. Оно
больше всего во время чтения ноты с кучей
параметров и командой (ноты в разных кана─
лах читаются не одновременно,так что опти─
мизировать надо именно отдельные ноты).
Также занимает время обработка портаменто
и вибрато,пока они длятся. Лучше всего бу─
дет, если ваш сонг вообще не содержит ко─
манд (это избавит плейер и от кода, счита─
ющего слайды). К сожалению, существующие
редакторы не позволяют автоматически пере─
писать любое поведение звука из паттерна в
инструмент.
2. Неиспользование накоплений в инстру─
ментах сокращает и ускоряет плейер. Это
регулярно используется в плейере для Info
Guide. К сожалению,автоматической развора─
чивалки накоплений нет, я делаю это вруч─
ную.
3. Если вы не используете сдвиг огибаю─
щей в инструменте, то сообщите об этом
кодеру (это очень трудно понять на глаз).
Обычно это нужно только для вибрирующей
огибающей. Убирание этого функционала из
плейера сокращает и ускоряет плейер.
4. Темпы ниже 3-го резко увеличивают ма─
ксимальное время воспроизведения.
5. Плейер для TurboSound отнимает в два
раза больше времени,чем проигрывание одно─
го AY. Если разложить такую музыку в ре─
гистры, может получиться несколько страниц
под музыку (например, в Nedodemo 2 музыка
заняла 4 страницы). Это сдерживает практи─
ческое использование TurboSound. Но он
неплохо подошёл бы к 3D демам, где фреймо─
вость не важна.
Реальные проблемы с воспроизведением:
1. Команда Зxxx на ту же ноту или с ша─
гом, превышающим расстояние между нотами.
Такие просто приходится удалять.
2. Сдвиг тона командами 1Oxx, 2Oxx - по─
ка не поддержано в плейерах (но таких тре─
ков пока и нет).
3. Сонг длиной больше 14 килобайт обычно
некуда класть в памяти...
Other articles:
