https://github.com/mamedev/mame/blob/master/src/mame/akai/mpc2000.cpp works well enough for reverse engineering at least several confirmed aspects:
- file formats
- screen layouts
Let's try to create a setup that allows automating such efforts.
We know that MAME has a Lua Scripting Interface, so this may play a role. Ideally we could give an LLM access, or we could use an LLM to write a script.
File formats
It's not trivial to figure out what to tweak where in the machine state to cause a certain effect to a written file. I'm sure with fancy LLMs with infinite tokens it can be done in a "Here's the PDF manual, have a nice day" kind of way. But maybe there's a more efficient way.
Filter
The current mpc filter is an approximation, tweaked by ear. Poking around in MAME should allow us to arrive at a near-authentic algorithm.
Envelope
The current mpc envelope is an approximation. As it turns out, the envelopes are not trivial to fully nail. See
env-description.pdf for illustration. It begins to explore the particularities of envelope behaviour, trying to map slope truncation behaviour against sample lengths, hold time, etc. Although https://github.com/izzyreal/envplayground/blob/main/main.py contains an algorithm that is probably more accurate than what mpc currently implements, I never switched it over, because most users don't care and don't notice that it's completely off, and if I make the effort of switching it out, I'd like to make sure it's an actual improvement, and closer to the real thing. If we can get an automated pipeline that involves audio analysis, we should be able to arrive at a near-authentic algorithm.
Other models
MAME also has an MPC60 and MPC3000. At the very least it would be cool to use them for verifying and improving the 60/3000 formats in https://github.com/izzyreal/mpc2000xl_kaitai/tree/main. But once we get a good pipeline/setup for RE, it's very tempting to build an exhaustive .ksy catalog of all formats that the 60, 3000, 2000, and 2000XL write, and for each firmware version.
https://github.com/mamedev/mame/blob/master/src/mame/akai/mpc2000.cpp works well enough for reverse engineering at least several confirmed aspects:
Let's try to create a setup that allows automating such efforts.
We know that MAME has a Lua Scripting Interface, so this may play a role. Ideally we could give an LLM access, or we could use an LLM to write a script.
File formats
It's not trivial to figure out what to tweak where in the machine state to cause a certain effect to a written file. I'm sure with fancy LLMs with infinite tokens it can be done in a "Here's the PDF manual, have a nice day" kind of way. But maybe there's a more efficient way.
Filter
The current
mpcfilter is an approximation, tweaked by ear. Poking around in MAME should allow us to arrive at a near-authentic algorithm.Envelope
The current
mpcenvelope is an approximation. As it turns out, the envelopes are not trivial to fully nail. Seeenv-description.pdf for illustration. It begins to explore the particularities of envelope behaviour, trying to map slope truncation behaviour against sample lengths, hold time, etc. Although https://github.com/izzyreal/envplayground/blob/main/main.py contains an algorithm that is probably more accurate than what
mpccurrently implements, I never switched it over, because most users don't care and don't notice that it's completely off, and if I make the effort of switching it out, I'd like to make sure it's an actual improvement, and closer to the real thing. If we can get an automated pipeline that involves audio analysis, we should be able to arrive at a near-authentic algorithm.Other models
MAME also has an MPC60 and MPC3000. At the very least it would be cool to use them for verifying and improving the 60/3000 formats in https://github.com/izzyreal/mpc2000xl_kaitai/tree/main. But once we get a good pipeline/setup for RE, it's very tempting to build an exhaustive
.ksycatalog of all formats that the 60, 3000, 2000, and 2000XL write, and for each firmware version.