ugocapeto wrote: a tad tedious, indeed.
Yeah. But if I were to guess, note data is probably packed something like this:
- Code: Select all
[Pattern 1] [Pattern 2] [Pattern 3] [Pattern 4] ...
Where each pattern contains all the channels, like...
- Code: Select all
[Synth1] [Synth2] [Drum1] [Drum2] [Drum3] [Drum4]
For each channel and pattern, you have all the info for each of the 16 notes:
- Code: Select all
[Note1] [Note2] [Note3] [Note4] [Note5] [Note6] [Note7] [Note8] [Note9] [Note10] [Note11] [Note12] [Note13] [Note14] [Note15] [Note16]
And the note data would be something like:
- Code: Select all
[Note] [Gate] [Volume] [Pan] [Kaoss X] [Kaoss Y]
...all of which are probably in one separate byte each.
So, that would be my starting point. Then, I would take an empty saved song (but still actually saved once, so the whole data is not zeroed!), and compare with an almost empty song. Make small variations, and see what changes. Change the note played, the gate, the volume... one at a time.
With some patience, you will eventually figure out the file format. The DS-10 save file is actually not that difficult to reverse engineer, since it's pretty easy to figure out which data actually needs to be saved. Even better, the saved data has a pretty natural and obvious (with some possible variation in the details, of course) way to be stored, so it's likely that the save file is organized like that. A binary save file for an adventure game or something would present a much greater challenge - you wouldn't know exactly what stats are saved, and there is no inherent way to organize the data, no inherent order.
in one way or another.