Это тебе так хочется. А на самом деле, независимо от того, кто и чем будет умываться, ты так и не смог опровергнуть ни одной из претензий в свой адрес, что собственно и является твоей основной проблемой.
И чем больше ты будешь испускать яда и тумана в этом смысле, тем крепче все будут убеждаться в том, что нет дыма без огня.
Ты как бы перепутал. Униженного и оскорблённого строишь из себя у нас ты, а не я.
Так что это не моя, а твоя работа — бегать за мной, сочинять херню про стенки и проч… и проч…
Хотя по факту, скорость твоего убегания наглядно всем продемонстрировала, кто из нас ощущает себя правым, а кто — виноватым. Уже не отмоешься.
Итого. Ты обратился ко мне типа как к эксперту в предметной области (иначе бы и обращаться именно ко мне не было смысла). Я попытался помочь чем могу (и это не первый раз), поделился с тобой реальным опытом и рассмотрел возможные решения, выделив из них два наиболее реальных, для разных исходных условий. Ты зачем-то начал спорить с одним из решений (хотя сразу стало ясно, что тебе нужно второе), допустив при этом минимум две ошибки, делающие дальнейшие выводы невалидными. Я тебе на них указал. Ты решил развить тему в новом направлении, приписав мне истерию, повторяемость, внезапно 'единственное' решение, а заодно самоутвердился, типа ты большой начальник и отсеиваешь людей по признакам.
Deflat-ом ты такой дамп сожмешь в лучшем случае в 2 раза, если сильно попотеть. Допускаю, что есть разные условия, и при определенных — это наиболее приемлимое решение. Извини, но это — не реальное решение задачи для всем мыслимых условий в данном случае.
И я спросил, не хочешь ли ты поучаствовать. Ответ «не хочу» вполне достаточен, зачем истерить?
Я поделился практическим опытом, как реальнее всего решить поставленную задачу, при наименьших трудозатратах. Зачем рассказывать мне, что это кем-то называется иначе и имеет недостатки? Да, дамп будет больше исходного модуля. Нет, не в сотни раз, есть простые способы сжатия таких дампов, а на STM32 явно найдутся и ресурсы для LZ-депакера, подобные дампы им отлично жмутся.
Я понял, что хочется полноценный XM-плеер, и указал на наиболее реальный путь его получения. Вложить в реализацию этой затеи неэффективным способом сотни часов моего личного времени — извини, не могу. У меня всегда завал чужих и своих проектов, причём на свои времени и сил не хватает катастрофически.
Достаточно сделать лог этой промежуточной информации, питча и громкости
Так сделано у Робуса в вайлдсаунде, если я не ошибаюсь. И называется это регдамп. Учитывая, что регистров поболее, чем у АУ, я вангую 200-300 байт на фрейм, это минимум. Нетрудно подсчитать размер дампа.
MPTracker пилили 20 (двадцать) лет. И он уже сам генерирует не вполне совместимые с другим софтом модули, добавляет в них информацию, которая вообще нигде и никак не задокументирована, кроме кода в исходниках. И этих исходников там километры, в них можно потеряться навсегда.
Конвертор без потери возможностей — почему же вдруг маловероятен? Разве PSG/VTX теряет что-то важное по сравнению с PT3? В плеере XM есть парсер паттернов и эффектов (самая неоднозначная часть). Есть генератор огибающих, управляемый парсером. На выходе они по сути каждый кадр выдают питч и громкость для каждого канала. Этот минимум параметров идёт на низкоуровневую часть ('вейвсинтез'). Достаточно сделать лог этой промежуточной информации, питча и громкости, и мы имеем в разы более простой по устройству плеер на конечном устройстве при 100% таком же результате.
Если нужно проигрывать миллион готовых модулей без промежуточной конверсии, значит однозначно надо брать готовые исходники и адаптировать. Писать с нуля, чтобы миллион модулей заиграл хоть как-то похоже на задуманное их авторами — это сотни человеко-часов, при минимальной мотивации. Сейчас таких ресурсов уже не найти.
Для меня стандартом является MPTracker, и я не видел ХМ чтобы в нем глючил. Сорцы открыты. Для референса, конечно, в лоб не портанешь.
Спасибо за ссылку на libxm.
Система отнюдь не закрытая, ХМ грузится как есть, лишь бы памяти хватало. Конвертор в что-либо проще ХМ-а без потери возможностей представляется маловероятным. А количество готовых модулей исчисляется реально миллионами.
Кроме ХМ там будет 32 канала вейвсинтеза, которые можно использовать параллельно с АУ, а значит плеер о котором ты говоришь может работать даже на хосте (на з80), ну или чо-нить для дем свое.
Голый AVR и Arduino давно освоил, разработал пару простых железок в стол (типа адаптера PS/2 мыши к приставке).
Написание именно высокоуровневой части XM-плеера дело крайне неблагодарное, так как формат развивался стихийно и потому не имеет спецификации. Лучшее, что есть — составленное энтузиастами исследование, неполное и неточное. Написание плеера с приличной совместимостью в такой ситуации может занять реально годы. Я считаю, что если нужна прямая поддержка XM (загружать XM-файлы без конвертора), то единственный эффективный путь — взять готовый плеер, в который уже были вложены необходимые усилия (например, github.com/Artefact2/libxm), и либо пробовать компилировать как есть (STM32 должен потянуть, вопрос совместимости кода с компилятором), либо переписывать по его шаблону на более низкий уровень.
Другой вариант, если система закрытая и не предполагает играть сами XM-файлы (т.е. есть только игры и демки, а просто взять SD, накачать туда XM и слушать нельзя) — сделать промежуточный легко и однозначно интерпретируемый формат, типа дампа регистров AY. Конвертер для XM в этот формат можно сделать на основе готового плеера на PC. Это быстрее и проще на всех уровнях. Я экспериментировал с этим подходом, писал 8-канальный плеер чиптюна (только 256-байтные циклические сэмплы) для SounDrive с конвертором из XM, но забросил.
И чем больше ты будешь испускать яда и тумана в этом смысле, тем крепче все будут убеждаться в том, что нет дыма без огня.
Я очень рад что ты так наглядно тут себя показываешь.
Так что это не моя, а твоя работа — бегать за мной, сочинять херню про стенки и проч… и проч…
Хотя по факту, скорость твоего убегания наглядно всем продемонстрировала, кто из нас ощущает себя правым, а кто — виноватым. Уже не отмоешься.
Более я по этой теме тебе никогда отвечать не стану.
И я спросил, не хочешь ли ты поучаствовать. Ответ «не хочу» вполне достаточен, зачем истерить?
Я понял, что хочется полноценный XM-плеер, и указал на наиболее реальный путь его получения. Вложить в реализацию этой затеи неэффективным способом сотни часов моего личного времени — извини, не могу. У меня всегда завал чужих и своих проектов, причём на свои времени и сил не хватает катастрофически.
Конвертор без потери возможностей — почему же вдруг маловероятен? Разве PSG/VTX теряет что-то важное по сравнению с PT3? В плеере XM есть парсер паттернов и эффектов (самая неоднозначная часть). Есть генератор огибающих, управляемый парсером. На выходе они по сути каждый кадр выдают питч и громкость для каждого канала. Этот минимум параметров идёт на низкоуровневую часть ('вейвсинтез'). Достаточно сделать лог этой промежуточной информации, питча и громкости, и мы имеем в разы более простой по устройству плеер на конечном устройстве при 100% таком же результате.
Если нужно проигрывать миллион готовых модулей без промежуточной конверсии, значит однозначно надо брать готовые исходники и адаптировать. Писать с нуля, чтобы миллион модулей заиграл хоть как-то похоже на задуманное их авторами — это сотни человеко-часов, при минимальной мотивации. Сейчас таких ресурсов уже не найти.
Спасибо за ссылку на libxm.
Система отнюдь не закрытая, ХМ грузится как есть, лишь бы памяти хватало. Конвертор в что-либо проще ХМ-а без потери возможностей представляется маловероятным. А количество готовых модулей исчисляется реально миллионами.
Кроме ХМ там будет 32 канала вейвсинтеза, которые можно использовать параллельно с АУ, а значит плеер о котором ты говоришь может работать даже на хосте (на з80), ну или чо-нить для дем свое.
Написание именно высокоуровневой части XM-плеера дело крайне неблагодарное, так как формат развивался стихийно и потому не имеет спецификации. Лучшее, что есть — составленное энтузиастами исследование, неполное и неточное. Написание плеера с приличной совместимостью в такой ситуации может занять реально годы. Я считаю, что если нужна прямая поддержка XM (загружать XM-файлы без конвертора), то единственный эффективный путь — взять готовый плеер, в который уже были вложены необходимые усилия (например, github.com/Artefact2/libxm), и либо пробовать компилировать как есть (STM32 должен потянуть, вопрос совместимости кода с компилятором), либо переписывать по его шаблону на более низкий уровень.
Другой вариант, если система закрытая и не предполагает играть сами XM-файлы (т.е. есть только игры и демки, а просто взять SD, накачать туда XM и слушать нельзя) — сделать промежуточный легко и однозначно интерпретируемый формат, типа дампа регистров AY. Конвертер для XM в этот формат можно сделать на основе готового плеера на PC. Это быстрее и проще на всех уровнях. Я экспериментировал с этим подходом, писал 8-канальный плеер чиптюна (только 256-байтные циклические сэмплы) для SounDrive с конвертором из XM, но забросил.