Откройте свой Мир!

SUPPLIER ..: TEAM AiR


H2O - Past and Future is an internal

production just for the fun of it

Lean back and enjoy !!!

AIR о своих H20 - предшественниках , но и называют пионерами Radium и говорят о том, что полезным было соперничество OxyGeN, ZONE, PARADOX и ArCTiC, участники которых затем перешли вместе в H20.
Дальше: Будущее в хороших руках и, так сказать, The Show Must Go On на долгие годы.
И совет от AIR : "Один совет: не коллекционируйте (софт), а делайте музыку!!" 




LINK HERE ! :ftp://ftp.untergrund.net/us...
 

Автор: kb/farbrausch [Перевод - Dimouse]

Источник: Incube #1

[В квадратных скобках будут примечания переводчика. Прошу извинить меня за корявый перевод: я не особо знаю английский и почти не разбираюсь во всех этих терминах. Надеюсь, несмотря ни на что, читать будет интересно, а может кому-то даже пригодится.]
1. Концепция

Вернемся в лето 2000, когда Chaos/Ex-Sanity (который чем-то похож на всем известного Powa из Elitegroup, но это уже совсем другая история) спросил, хочу ли я участвовать в создании музыки к, как он ее назвал, "лучшей 64kb интро всех времен". Когда я попросил его показать интро, он сказал, что еще ничего не закончено, но он и Fiver2 покажут кое-что в ноябре, и это меня наверняка убедит.

Так оно и случилось. Черт. Каждый год я хочу отдохнуть от всей этой сценерской жизни, и каждый год одна и та же история: "Давайте выиграем The Party". Мне НИКОГДА не удастся скрыться от этого.

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

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

Итак, требовалось как-то запихнуть саундтрек в 16kb в сжатый exe-шник, который мне предоставил Chaos... мне осталось лишь поместить туда столько моих любимых вещей, сколько возможно.

Но как? Давайте взглянем на решения, которые существовали раньше:

1. Обычная трекерная музыка с использованием MXMPlay/W или MiniFMOD или чего-нибудь еще Ну, если коротко - НЕТ. Сэмплы занимают место, и даже эти чипповатые, похожие на шум сэмплы, которые мне бы пришлось использовать, заняли бы слишком много. Кроме того, звучание всех этих 64kb интр - конечно, есть музыканты, способные на создание хороших мелодий при таких небольших ресурсах, но большинство 64kb-интро саундтреков не прожили бы долго в "реальном мире".

2. Использование модулей с прекалькулированными сэмплами в softsynth'е (путь Stash) Неплохо. Но все еще не то, что мне надо... Требуется держать программный синтезатор И проигрыватель модулей в exe-шнике, и не остается такого понятия, как "удобство в использовании"... Я уважаю Probe'а и других за полученные ими результаты, но я как музыкант лучше уйду со сцены, чем буду составлять музыку к демо, набирая шестнадцатеричные числа в softsynth'е, перекомпилируя его, генерируя сэмплы, переходя в трекер, загружая сэмплы заново, понимая, что они оказывается не подходят и т.д. Это решение может работать, но убивает весь рабочий настрой и креативность. К тому же, я пробовал это годом ранее, и независимо от грустного факта, что наша интро тогда так и не была сделана даже наполовину, музыка, которую я сделал для Mekka&Symposium 2000 invitation intro, используя этот метод, была действительно отстойная.

3. Да, еще же остаются FM synth и General Midi wavetable чипы на современных звуковых картах. Но, так как все, что они могут это звучать "дешево и стильно", это вовсе не решение. Но главное, нельзя быть уверенным, что композиция будет звучать одинаково на всех компьютерах.

Если подумать, то трекерная музыка в любом случае - это отстой. Взгляните: весь формат модулей, способ, каким паттерны показываются, располагаются в памяти и проигрываются, был создан по одной простой причине: Paula. MOD'ы были созданы, чтобы самым простым из возможных способов ("простым для кодера и процессора", а не "простым для музыканта") заставить амижный звуковой чип (который называется Paula) играть сэмплы, только и всего. И к сожалению все другие программы последовали за этой парадигмой, хотя MOD формат был создан временно, до тех пор пока не появится лучший амижный процессор или даже лучший софтверный микшер. И, что еще хуже, все новые и известные трекеры содержат ТОННЫ лишнего, чтобы сделать их как можно более похожими на оригинальный SoundTracker. И IMHO, без убедительной причины.

К тому же мы живем в 2001 году. Процессоры сейчас будут побыстрее, чем тогда, музыкальные программы эволюционировали, кульные программы типа Buzz'а или плагинов для всех форматов сейчас в изобилии... и я просто не могу понять, почему мы должны работать с моно-сэмплами без каких-либо эффектов или модуляций для создания хорошей музыки. Говоря о качестве, каждый ребенок, пишущий музыку, может просто посмеяться над возможностями трекеров... и будет прав.

Ok, давайте подведем итог: все существующие решения сосут. Но что же делать? Я хочу гибкую, хорошо звучащую звуковую систему, подходящую для создания произведения искусства с качественным звуком (и вокалом :)... И надо, чтобы она поместилась в 16kb со всеми музыкальными данными. Звучит нереально, не так ли?
1.2 Нововведение в создании идей.

Не совсем.

Давайте пороемся в одном из самых старых компьютерных музыкальных стандартах: MIDI. Когда я говорю о МИДИ, я подразумеваю оригинальный "Music Instrumentsd Digital Interface" стандарт, который включает определения для серийного интерфейса (стандартный RS232 асинхронный протокол, 32500 бит/сек, один стартовый и один стоп-бит, без четности, без handshaking, используя TTL напряжение и этот всем известный 5-ти пиновый DIN разъем и эти еще более известные цепи нарушения связи [надеюсь, я правильно перевел]) и определения простого протокола, способного передавать события такие, как "клавиша нажата", "клавиша отпущена" или "колесо модуляции немного прокручено вверх". Я также имею в виду файловый формат SMF (стандартные миди файлы, эти .mid), который содержит не более, чем просто "временное отображение" всех событий, относящихся к музыке. То что я НЕ имею в виду, это "General MIDI" стандарт (и все его производные), который определяет различные стандартные звуки и, то, о чем большинство людей думают, когда слышат слово МИДИ. Это неплохой способ распространять плохие кавер-версии популярных песен по сети или для старых досовских игр и тому подобного. Как было сказано ранее, это звучит, э-э-э, дешево.

"Итак... Современные процессоры довольно быстрые. Также, сейчас век TnL 3D карт, поэтому процессору не нужно почти ничего делать в демке. У меня есть все время в мире!"

(на что Chaos ответил что-то вроде "если мое интро будет тормозить со скоростью 2 фрейма из-за твоего synth'а, ты умрешь", но кого это волнует)

Итак, как насчет того, чтобы написать синтезаторную систему полностью в реальном времени, которая просто создает МИДИ-события и отправляет их в .mid? Да, это будет жрать (и в действительности жрет) много процессорного времени, но в этом есть много преимуществ.

1. .mid плеер ГОРАЗДО меньше XM плеера... просто читает файл, ждет следующего события и отправляет некоторые команды synth'у... нет обработки эффектов, ничего. Хорошее качество звука, реалтаймовый синтез гораздо круче прекалькулированных сэмплов... Линии будут звучать более "естественно" (как с аналоговым оборудованием, без двух одинаково звучащих звуков), и мы сможем сделать длинное фильтрование разверток и модуляций без того, чтобы жертвовать несколькими мегабайтами памяти и драгоценным секундами прекалькуляции для этих звуков.

2. Если synth все равно создает МИДИ-команды, почему бы ни подключить небольшой GUI для редактирования звуков в нем и подсоединить его к MIDI секвенсорной программе по вашему вкусу? Таким образом вы сможете сочинить все песню в Cubase (или Logic или Cakewalk или zTracker или Modix или то, что предпочитаете вы) и любое изменение звука будет всего лишь два мышиных клика (или нажатие кнопки в плате MIDI контроллера:) и работает немедленно, вместо "изменить, срендерить, загрузить, попробовать, не подходит, изменить, срендерить...".

3. Один побочный эффект заключается в том, что музыкальные данные в .mid файлах хранятся в немного более чувствительном виде, чем в трекерных паттернах (которые хранились для более простого доступа к ним процессора M68000 и после этого не изменившихся) и как правило меньше (причем для меня все равно не достаточно, но об этом позже) Возможно, кто-то из вас жалуется, что этим способом он не сможет проигрывать сэмплы. Но добавление проигрывателя сэмплов в softsynth - это 20 строчек в ассемблере или 5 строчек в C++ при хорошем знании этих языков. Может это больше программирования, но это не то, что я называю проблемой. Ok, в следующем разделе вам потребуется знание MIDI-протокола и возможно .mid формата, так что я оставлю это как домашнее задание до продолжения чтения.
2. Почему SMF файлы меньше?
2.1 MIDI файлы меньше? wtf...

Если вы немного знакомы с МИДИ коммуникациями и .mid файлами (которые, как было сказано, являются всего лишь логом событий), вы можете спросить, с чего это я решил, что они станут после сжатия меньше, чем модули.

Предположим сначала, что нам не требуется сжимать музыкальные данные. EXEшник будет все равно сжат, скорее всего RLE или LZ (и, возможно, с entropy coding). Поэтому никто не запрещает нам сделать 1 мегабайт нулей - они превратятся во что-то вроде 4 байт после сжатия. Повторяющиеся или похожие вещи также неплохо сожмутся.

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

Вторая проблема заключается в том, что все модуль-плееры, существующие на сегодняшний день (единственное исключение - это, ИМХО, Digitrakker), хранят данные в "по-рядовой", а не в "по-канальной" форме, а это означает, что данные, которые часто повторяются (например ваш басовый барабан на каналах 1,2,3:) чередуется или "разбрасывается" с изменяющимися данными (мелодия, аккорды, и т.д.), так что LZ-паковщик найдет что-нибудь, но сможет сжать лишь небольшие куски данных, а не полностью оптимально.

Да, но стандартные МИДИ файлы гораздо хуже. SMF действительно "компактный" формат, он фокусируется на сохранение каждого байта. Это круто для несжатого размера файла, но с ним не справятся стандартные алгоритмы сжатия. Тот факт, что такой файл - это один поток данных, даже не разделенный на каналы (это справедливо для 0 формата, файлы формата 1 могут иметь произвольное количество треков, но это все равно вскоре станет бесполезным), также ничем нам не поможет.
2.2 Как удовлетворить LZ-компрессор.

Но с этим можно кое-что сделать. Трюк заключается в том, чтобы пересортировать МИДИ данные и сгруппировать похожие события вместе. Таким образом я разделил МИДИ-поток по следующему критерию:


МИДИ-канал.
Тип события (Note, Control Change, Program Change, Pitch Bend, Channel Pressure, Rest)
для контроллерных событий: номер контроллера.

После разбивки у меня было несколько сотен отдельных потоков (некоторые из них, конечно, пустые), которые содержали данные типа "все изменения контроллера 2 на канале 10". Вы видите, что в нашем примере с басовым барабаном, хороший LZ-компрессор обработает поток с "нотами в канале 1" и подумает что-то вроде "ох, одно и то же событие каждую четверть ноты по всей песне" и заменит все эти ноты одним словом: "tekkno".

Но, конечно, этого недостаточно. Если в вашей песне больше одного басового барабана, она скорее всего содержит последовательности, которые переходят в другие питчи. Обычно, LZ-паковщик не распознает такие перемешанные паттерны, и он также не распознает продолжительный controller slide от 0 до 127. Поэтому применим дельта-кодинг ко всему... к timestamps, к номерам нот, к информации о скорости, к значению контроллера, просто ко всему. Controller slide от 0 до 127 станет чем-то вроде {always_the_same_time_delta,1} за событие и все последовательности нот станут "разъединенными" от своих базовых нот, т.к. кодируются только разница питчей нот, и LZ-компрессор определит эти слабые повторения как надо.

Также, почти все EXE-паковщики сжимают данные byte-wise способом. Проверьте, что используемый вами компрессор хорошо пакует ваши структуры потоков. Я не буду обсуждать все это дальше (чтобы оставить себе хоть небольшое преимущество), но вы поймете, что я имею в виду, если подумаете над этим, обещаю:)

Вы можете убедиться (надеюсь, убедитесь), что написать .mid плеер, который должен иметь дело с около 200 дельта-кодированными потоками и их timestamps в памяти и расписывать каждое событие в правильное время - это не слишком тривиальное дело. Фактически, оказывается, что код плеера будет больше - обычный .mid плеер может поместиться в 500 байт, плеер моего измененного формата занимает около 1.5K, несжатый и в неоптимизированном C++. Но это все равно оплачивается потОм. 11-минутная основная тема в Fr-08 занимает около 120K в .mid формате (PKZIP делает из этого что-то вроде 20K). После преобразования и добавления нескольких сотен байт звуковых данных, готовый для проигрывания файл занимает около 180K... а после применения EXE-компрессора остается всего 4K. Отношение сжатого файла к несжатому - 1:30, что ИМХО круто (и безусловно лучше, чем отношение 1:10, которое я бы получил со стандартными .mid файлами).

Итак у нас есть концепция, файловый формат для музыки... давайте же получим звук из PC :)
3. Простейшая система.
3.1 Введение.

Ok. Мы выбрали оружие и файловый формат, так что можно начинать. Сразу появляется следующая проблема: как получить звук из этого серого гроба?

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

Первый вопрос: какой звуковой API использовать? Предполагая, что мы хотим использовать Windows для воспроизведения звука, у нас есть две возможности: waveOut ("нормальный" способ, которым PC создает звук)

Мой выбор - Direct Sound, по простым причинам:
API нужно меньше вызовов, а главное, только один ввод (а это хорошо для размера файла)
Дополнительные буферы могут засрать производительность, но это самое безопасное средство получения звука из вашего компьютера, и они могут быть даже аппаратно ускорены, и в некоторых случаях быстро.
DirectSound предоставляет вам легкий и надежный способ синхронизировать внутренние часы с аудио потоком.
3.2 DirectSound плеер.

Инициализация процедуры DirectSound довольно проста (см. DirectSound SDK для дальнейшего разъяснения): вызовите IDirectSound интерфейс с помощью DirectSoundCreate, установите кооперативный уровень на установку "priority" ("exclusive" было бы еще лучше для демок, только проблема в том, что она не поддерживается, а фактически является тем же самым, что и "priority", по крайней мере с DirectX8), создайте первичный и вторичный буфер, установите оба на предпочитаемый вами формат вывода (я рекомендую 16bit 44.1KHz signed stereo PCM), заблокируйте весь вторичный буфер, очистите его, разблокируйте его снова...

... затем проиграйте все это.

Так, ЧТО проиграть-то? Нам надо будет как-нибудь заполнить буфер данными. Опять же здесь два способа:

Использование второго thread (также, как и таймер IRQ в Досовские времена):

Мы создаем thread, ответственный за рендеринг звука. Этот thread будет работать независимо от нашей основной программы, ему не потребуется Windows messaging или что-то еще, так что это действительно удобно. А если мы поставим приоритет thread'а на значение, большее чем обычно, он скорее всего не будет прерываться другими процессами. Единственная проблема - наш звуковой thread будет тратить процессорное время как раз в тот момент, когда нужно закончить рендеринг фрейма прежде, чем следующий видео фрейм должен начать обрабатываться, и таким образом может повлиять на частоту отображения фреймов очень неприятным образом.
Поместить его в главный цикл:

Мы просто вызываем процедуру рендеринга звука в главном цикле. Тогда она не будет мешать остальным процедурам, но останется одна большая проблема: если один проход нашего основного цикла будет больше, чем звуковой буфер, то звук будет глючить. Если вы пробовали запускать Quake 1 на 486-ом компьютере, то вы знаете, что я имею в виду.

Моим окончательным решением был гибрид этих двух способов. Первым делом я решил, что я хочу использовать звуковой thread для вывода. Для упрощения, этот thread был простым циклом, который делал следующие вещи:


Получал текущую проигрываемую позицию буфера
Генерировал и заполнял буфер с последней известной позиции до текущей
Ждал немного
Переходил на начало, если переменная "exit sound thread request" не установлена.

Я знаю, DirectSound SDK и многие другие источники могут составить впечатление, что double-buffering и печально известный DirectSound's Position Notifications жизненно необходимы, но на самом деле это не так. Единственное, что необходимо - это вовремя заполнять буфер, а способ выбора, что значит "вовремя" - это полностью ваше решение. Например, моя команда ожидания ждала где-то около одной четверти размера буфера, так что всегда оставалось много запаса в буфере.

Теперь по поводу проблемы интерференции с процессором. Я хотел, чтобы рендерер synth'а был синхронизирован с движком видео-рендера без жертвования преимуществами отличного фонового проигрывания. Я достиг этого, определив событие синхронизации (см. Win32 SDK для nearer спецификаций), которое могло "запустить" цикл звукового thread'а, так как я заменил команду Sleep() на WaitForSingleObject(), которая выходит, либо по истечении указанного времени, либо, если событие было установлено.

Таким образом, я получил возможность запуска события в основном цикле с помощью SetEvent(). Из-за внутренних действий виндового планировщика (scheduler), а также из-за того, что мой thread работает на высоком уровне приоритета, основной thread приостанавливается, а звуковой thread делает один проход цикла. Как только он достигает WaitForSingleObject() снова, основной thread продолжается. Так что это похоже на непосредственный вызов в процедуре генерации звука - и как только ваш главный цикл будет занимать достаточно большое количество времени, чтобы звук работал стабильно, значение timeout'а звукового thread'а начинает действовать и снова "создает звук на фоне".

Если вы хотите избежать слишком частого вызова звукового thread'а, просто вставьте в цикл "minimum time check", который пропускает рендер, если недостаточное число сэмплов было проиграно со времени предыдущего вызова.
3.3. Время ожидания и синхронизация.

Давайте вспомним ключевое свойство того, что мы сейчас делаем:
"Цель этой звуковой системы - воспроизведение музыки."

Может быть это и тривиально, но эта фраза - ключ ко всем проблемам со временем ожидания, просто потому, что этих проблем больше не будет. Когда вы просто проигрываете кусок музыки, нет ничего, чтобы могло произойти непредсказуемо. Вы проигрываете последовательный поток данных, который может идти непосредственно из WAV файла и не изменится за все время проигрывания. Таким образом, вы можете увеличить или уменьшить время ожидания как вам требуется, на результат это не окажет никакого воздействия - все равно ясно, что будет проигрываться, и никого не будет беспокоить, если звук будет идти из колонок немного позже.

Никого не будет беспокоить? Если уж я хотел синхронизовать видео и звук, то лучше все-таки БЕСПОКОИТЬСЯ о том, когда на самом деле будет играться звук. Большинство людей попытаются уменьшить время ожидания как только возможно, для того, чтобы приблизить видео к звуку по мере своих сил.

Но они забывают одну вещь: реальное время ожидания известно. Это - ровно длина одного звукового буфера (плюс, возможно, 20мс дополнительно на время ожидания DirectSound микширования, но в большинстве случаев вы можете без проблем пренебречь ей). Так что же нас останавливает "перевести назад" наши часы на время одного звукового буфера? Ничего. После чего мы счастливо обнаружим, что находимся в полной синхронизации.

Итак, код синхронизации нашей демки выглядит следующим образом:


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

И voila, у нас есть исходный код, который находится в полной синхронизации с аудио выводом и никогда не перестанет быть в ней. Только не забудьте, что он должен начинаться на минус размере буфера, поэтому лучше сделайте ваши переменные таймера знаковыми и ждите некоторое время до начала визуализации:)

Так как это было бы слииииишком легко, то конечно вам следует принять к сведению несколько вещей: функция GetPosition в DirectSound'е может быть иногда неточной. Вы ДОЛЖНЫ определить DSBCAPS_GETCURRENTPOSITION2 для второго буфера, вы ДОЛЖНЫ изолировать все функции (цикл звукового thread кроме Sleep()/WaitForSingleObject() вызова и всю функцию GetTimer()) в критические разделы или mutexe'ы (загляните в Win32 SDK), поскольку иначе у вас будут проблемы с синхронизацией...

... но даже после этого величина таймера может скакать немного через каждые несколько секунд, особенно с плохо написанными драйверами саундкарт (can you spell creative?). Единственное найденное мной решение - проверять разницу (дельту) таймера от последнего до текущего вызова. Если она была больше, скажем, половины размера буфера, текущая позиция игнорировалась и моя функция возвращала вместо этого последнюю известную позицию. Это далеко не идеальное решение, но как я уже сказал - это происходит только один раз за 20-30 секунд, и никто не заметит небольшой рассинхронизации время от времени.

Если вам нужно синхронизовать демо с определенными нотами/событиями в музыке, не тратьте времени, пытаясь синхронизовать позицию музыки и часы (это возможно с небольшой FIFO очередью, которая получает корреляцию между положением и количеством сгенерированных сэмплов, когда плеер проходит позицию и которая считывается функцией GetSongPosition до "реального" значения таймера, но кого это волнует) - просто расширьте ваш плеер функциями, которые вычисляют таймерную величину из позиции песни и наоборот, используйте их в вашей авторской программе и храните только таймерные величины для событий уже в реальном демо. Это значительно упрощает жизнь (а еще сокращает длину плеера, без потери способности ультра синхронизации).
3.4. Цикл рендера.

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

Все же делать размер буфера степенью двойки - это плохая идея.

Времена, когда ассемблерные кодеры использовали операцию AND для масок в буферных оффсетах закончились. Один или два цикла для операций сравнения сильно не навредят. Так что нет смысла делать размер буфера степенью двойки, если конечно вы не привыкли к этому. На самом деле даже лучше будет, если это не так. Я не буду вдаваться в подробности, но если вы знаете как работает кэш, вы поймете, что процессор может управлять кэшем лучше, если буфер начинается со "странных" адресов, особенно, если вы используете несколько буферов одновременно (например, в одном цикле). Просто сделайте адреса буферов кратными 32, но не степенью двойки (или оставьте небольшое пространство между буферами, даже одного dword'а достаточно) или вам же хуже.

Кроме того, используйте по меньшей мере 32bit integer буфер или, еще лучше, 32bit float буфер для "финального" сигнала на выходе, когда он покидает этап рендера. Это утверждение также применимо ко всем промежуточным смешивающим буферам, поскольку 16bit точность слишком медленная (их обработка создаст слишком много звукового шума, если сделать ее больше чем пару раз) и у вас не будет НИКАКОГО места, если сигнал будет обрезаться. Для integer'овых буферов - рассматривайте их как 1:7:24 fixed point values, а для float'овых буферов, нормализация сигнала при 1.0 - это неплохая идея.

Итак, "рендерная" часть звукового thread цикла выглядит вроде этого:


вычесть последнюю позицию из текущей позиции (modulo the buffer size) (это даст вам количество семплов для генерации за один проход цикла)
необязательно: выровняйте ее по вашей буферной гранулярности (newsize = size - (size MOD granularity), если newsize становится равным нулю, чтож, это нормально, придется генерировать не меньше, чем 4 гигабайта данных:)
далее вызовите функцию генерации, чтобы сгенерировать определенное количество сэмплов в промежуточный буфер
заблокируйте DirectSound буфер начиная от последней сыгранной позиции.
сконвертируйте и clip (!!) буфер вывода в знаковые 16битов и скопируйте его в DirectSound буфер.
разблокируйте DirectSound буфер
прибавьте число сгенерированных сэмплов к последней позиции (MOD buffersize - по модулю buffersize)

Таким образом ваша функция-рендер будет вызываться просто с destination буфером и количеством сэмплов, и вы сможете написать свой синтезатор или плеер или что угодно полностью ОС/платформенно независимо. Чтобы портировать систему, просто перепишите код, отвечающий за вывод звука. То же самое относится к использованию waveOut или .wav рекордеров или вашего любимого MP3 плеерного плагина, или если вы хотите сделать все это VST2 плагином (используйте нормализованный и pre-clipped флоатовый буфер в этом случае:) и т.д.

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

"Да, действительно, нам теперь нужен синтезатор"

Хорошо, но это будет позже. У вас теперь достаточно работы, если вы дочитали до этих строк, а после этого все станет гораздо серьезнее. И второе - я еще не закончил этот цикл статей, так что ждите.

В любом случае, я надеюсь, что все это вам чем-то помогло, если у вас есть вопросы, комментарии или предложения - просто напишите на kb@kebby.org или найдите меня на IRC:)

До встречи... Таммо "kb/farbrausch" Хинричс.

[существует еще одна статья kb из этого цикла, которая посвящена программным синтезаторам, и которую я еще не перевел]

Перевод - Dimouse, 2003-2004.

LINK  http://www.xakep.ru/magazine/xa/014/xa_014.pdf
 

В написании  AMIGA OS4 участвовала Амижная демо-группа UNIVERSE.
Судя по стилю демки
One Geometry (AmigaOne démo by Universe)
 
 AMIGA OS4 TRAILER :
 
Shared link  http://movies.intuitionbase.com/multimedia/os4intuition.avi
 
 
 
 

http://www.mindcandydvd.com/ 

http://www.demodvd.org/

Легендарный Commodore 64 (1982-1994)


"Основным конкурентом Commodore 64 в области графики и звука были 8-битные компьютеры Atari. В те времена IBM PC-совместимые машины имели видеокарты, способные выводить только текст на монохромные зелёные мониторы, и звук из писка и визга, воспроизводимый встроенным низкокачественным динамиком.

Благодаря широким возможностям в области вывода графики и звука, Commodore 64 принято считать родоначальником компьютерной субкультуры, известной как демосцена (см. также Commodore 64 demos(англ.)). И на рубеже тысячелетий он (наряду с ZX Spectrum) остаётся основной demo-машиной, особенно в области музыки (его музыкальный спецпроцессор SID используется в специализированных звуковых картах для PC). В остальных направлениях, однако, C64 потерял лидирующие позиции, когда на в середине 80-х сцену вышли 16-битные Atari ST и Commodore Amiga; на C64 остались несгибаемые энтузиасты.

Прошло 20 лет после появления С64, но демосцена не умерла. Продолжают разрабатывать новые игры. Одна из них заслуживает особого внимания — Enhanced Newcomer, находящаяся в разработке уже 10 лет.

Различия между PAL- и NTSC-машинами привели к проблеме совместимости между C64, предназначенными для рынка США и Канады, и предназначенными для других стран. Большинство демок способны работать только на PAL-машинах."

Links to WiKi: http://ru.wikipedia.org/wik...

Многие наверное знают этот плеер, но для тех кто не знает то...

XMPlay is an audio player, supporting the OGG / MP3 / MP2 / MP1 / WMA / WAV / CDA / MO3 / IT / XM / S3M / MTM / MOD / UMX audio formats, and PLS / M3U / ASX / WAX playlists.

Понятно что ключевые слова здесь  IT / XM / S3M / MOD  :) Тот же Winamp с плагинами по моему мнению играет трекерную музыку... ну очени фигово...

Сайт разработчиков, откуда собственно и качать http://www.un4seen.com/

P.S. Собственно я использую два плеера XMPlay http://www.un4seen.com/down... и Foobar (Dr.Death foobar 2000 pack) чего и вам советую :)
P.P.S. http://www.foobar2000.ru/

Почему в кряках всегда играет какая-то музыка?
А: Музыка мерзкая, и этим кряки оповещают, что действие противозаконно.
B: Каждый кряк - это творение, оно должно быть красивым...
(из сетевого форума)

Да, было всякое: редкие красивые композиции, трояны, томные вздохи барышни при генерировании ключа для mIRC (этот crack у меня лежит до сих пор). Winamp молчал, но колонки работали, как часто случается ночью. Много чего может быть зашито в махонькую программу.Если хотите, чтобы вас услышали, существует и другой путь (нет, не новомодные подкасты). Это создание специальной программы-«чипдиска» (от англ. сhipdisk) - подборки трекерной музыки. Русским эквивалентом у нас будет «музыкальная шкатулка» - именно это слово отражает суть такого рода программ. Всё в себе: звук, программный код, который отвечает за его воспроизведение, и, как отличительная черта, - страсть к экстремально малым размерам получаемого файла. Чем не музыкальная шкатулка?

Cовременные левши: Razor 1911, Farbrausch etc.

Кто делает подобные вещи? Довольно большое количество различных хакерских (в хорошем понимании этого слова) групп. Первое знакомство стоит начать с Razor 1911 и Farbrausch. Есть множество и других, но сегодня речь именно об этих ярких представителях демосцены.[ продолжение тут → ]

Demo design 3d programming FAQ.
Демо дизайн для начинающих.
Demo.Design.FAQ.
Еще один FAQ.

Все знают группу farbrausch и ее v2 synthesizer system. Новая версия движка дорабатывается, как улучшенный вариант V2. Не исключено что она будет платной, либо останется закрытым проектом. Предлагаем сборник музыкальных работ в формате v2m (970kb) и небольшой самостоятельный плеер формата (30kb) на движке libv2.

(По материалам trackers.fmf.ru)

EXE-музыка

Плеер Ixalance - это как-то незаслуженно незамеченная мною в свое время уникальная программа. По сути - это синтезатор, управляемый крохотного размера (музыкальными) файлами. Его авторами являются The Black Lotus and Jarno Paananen.
Сам синтезатор, судя по обеспечиваемому звучанию, - очень серьезная штука. Его звук, ну, просто живой! При этом занимает он около 160 Kb в EXE.
Музыкальные файлы к нему - это небольшие модули размером до 20 Kb.
Будучи встроенным в другую программу или игру, такой синтезатор может обеспечить просто великолепное музыкальное оформление при минимуме объема данных.
Скачать комплект Плеер Ixalance + 24 отличные музыкальные композиции можно здесь. (всего 417 Kb).

(по материалам websound.ru.)

Рекомендую не смотреть все подряд, лучше http://scene.org/awards.php за разные года для начала... :)

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

Меня гложет один вопрос - и все таки, в чем и на чем лучше писать демку - на asm, c, и других языках либо пользоваться специализированными тулзами типа Werkkzeug, Addict, Demopaja и так далее? Пишите, очень интересно почитать мнения.

З.Ы. Недавно выкачал почти весь архив интр 4-64к и музыки с ftp.scene.org. Работа встала. Блин. Когдаж я енто всё пересмотрю? о_О

Для меня демосцена началась с покупки UltraSound-ой карты (Gravis Ultra Sound (GUS))... Саунд бластер в то время просто курил :)
На диски к этой карточке прилагался CD... собсвенно где были представлены некоторые Демки... и тут понеслось Future Crew http://en.wikipedia.org/wik... в то время конечно рулили.... К слову сказать многие трекеры и демо были заточены ТОЛЬКО под эту карту... это говорит о ее значительном влиянии....

Вчера запустил на амижном эмуле (WinUAE) Slam TILT http://hol.abime.net/1972 и Speed Ball http://hol.abime.net/2047 ...просидел практически весь вечер :) к слову о качестве игр и демок прошлого....
Проблема всего современного и нового "навороченного" программного обеспечения - это множество глюков и соотв-но постепенный потом выход "заплаток"... НО на это есть определенные причины: такие как многомиллионные бюджеты... огромные команды разработчиков и так далее... В итоге намного больше повышается сложность такого проекта в целом... плюс определенные ограничения по времени и жесткая конкуренция со стороны других разработчиков...
Что касается ДЕМОСЦЕНЫ... то моему мнению она развивается... переживает не лучшие времена, но развивается и скорее преобразуется в ближайшем будущем во что-то другое... классические "олдскульные" конкурсы возможно постепенно будут заменяться другими....

>>Посвящается пока что малоизвестному направлению в программировании, культуре, музыке и графике - ДЕМОСЦЕНЕ.

Демосцена - НЕ малоизвестное направление. Движению сценеров уже более 30 лет. Сцена началась, когда появился первый хакер. Сцена постоянно развивается. Конечно, как и у любого направления в культуре, у сцены были и взлеты и падения. На данный момент она находится в стадии упадка. Раньше, в 80х-90х годах не было таких аппаратных возможностей и сценеры, чтобы показать свою крутизну, пытались выжать из тогдашнего убогого железа все по-максимуму. Использование нестандартных частот экрана, воспроизведение музыки посредством порта LPT.... Скольких бессонных ночей это стоило! Конечно, сейчас есть люди, которые до сих пор творят на Амигах, Спеках и Коммодорах, но их очень мало. А писишники и игры для них стали настолько наворочеными, что всякими прибамбасами уже никого не удивишь. Да и энтузиастов, пишущих на асме и бъющихся над оптимизацией кода под 64 килобайта уже почти нет. Да и зачем, если сейчас жесткие диски выпускают до 1 терабайта? Конечно, меня привлекает демосцена как искусство, но я в ней ценю не размер демок, а качество материала. Вот так.

http://www.demoscene.ru - Российский сайт о демосцене
http://scene.org.ru - Еще российский сайт
http://www.trackers.fmf.ru - Трекерная музыка. Плееры, трекеры....
http://www.pouet.net - Крупнейший мировой сценерский портал
http://www.modarchive.com - самый большой в сети архив трекерной музыки

Рекомендую посмотреть следующие демки:

Farbrausch - все
Orion - What is a demo?
And - Zoom3
Kewlers - Variform
Umlaut Design - You Die!
Hansa - Wow Factor
Haujobb - We took the Greenpill
Popsyteam - Vip2(Forsaken)

и так далее...

http://www.farb-rausch.com/ - очень уважаю эту группу
http://www.thesands.ru/
http://www.4players.de/4sce...
http://scene.rpod.ru/ - scene. RussianPodcasting... только редко обновляется :(

P.S. scene.org, demoscene.ru не буду упоминать думаю все знают :)

Трехмерные миры, развивающиеся в реальном времени, в сочетании с стильной рисованной графикой, дизайном, максимальной синхронизацией с музыкой...

И все это не видеоклипы, а программки размером 64 kb (шестьдесят четыре килобайта), просчитывающие и воспроизводящие завораживающее действо в реальном времени! Не используя 3d-акселераторы, не используя midi-синтезаторы дорогих саундкарт, базируясь только на чистом ассэмблерном коде, эти шедевры программирования и дизайна вряд ли оставят кого-либо равнодушным.

www.demoscene.ru

Ребята! Вы жжете! Демосценеры-вампиры! Держите мою кровь! Свежая, однако! Макс, я тебя нашел!!!

Демосцена - программа, демонстрирующая трёхмерные пространства и эффекты, дополненные звуковым оформлением. При этом демосцена имеет очень малые размеры и разделяется на категории: 4кб, 32кб, 64кб - основные; 128кб, 256кб - 12мб; и Wild Demo - более 12мб.

Нам нужна свежая кровь! Смелее вступайте в наше сообщество!