DMF2ASM and XMYM Tracker

[RevEng]

I've released dmf2asm and the included xmym tracker at github. If you're planning on giving a try to composing music in DefleMask, check out one of the DefleMask tutorials on youtube, and then please give the dmf2asm README.txt a once-over first, because you need to construct the music with certain restrictions.

 

I've included 7800basic-based and assembly-based tracker examples. The assembly one is less glitzy than my 7800basic version, purely as a function of my free time. If anyone wants a glitzy assembly example, feel free to contribute one.

 

Please report any bugs encountered here or at github, and feel free to discuss technical details here.

[RevEng]

Just wanted to also put out that I'll be looking at more features in the coming weeks...

• Initial instrument loads being auto-split over a few frames. This should allow mid-game song changes without burning a lot of CPU.
• Support for tick1 different from tick2. Deflemask has two different note-row-timing delays; one for even rows, and one for odd rows. It's a bit weird, but I think I can support this without a lot of heartache.
• Mid-song instrument changes. This one is a lot more involved, but it would be cool to have up to 16 instruments at the ready.

 

[RevEng]

I figured I'd make this thread a bit of a dev log of sorts for the time being.

 

I made the tick1!=tick2 update, though I wouldn't recommend using differing ticks generally. If you use a differing ticks, dmf2asm can't squeeze your pattern down by removing redundant odd rows, since the timing will be different between even and odd rows.

 

I also added code to defer the final all-notes-off at the end of a song. In the previous version the all-notes-off was issued too quickly after the final notes in the song, which caused a bit of distortion. (e.g. that cool, but unplanned, whoosh ending at the end of the Zanac demo.)

 

I've decided that mid-song instrument changes are going to be implemented as start-of-pattern instrument changes. Otherwise I'll wind up doubling the pattern data needed for songs. This may also bring some minimum speed requirements, though nothing too crazy. I just need some frames between  

 

I also had a neat idea. Presently the high bit of the note data is only used for the rest marker, when note=0xff. If a note value of >127 and <255 is seen by XMYM, the tracker could save state and jump to a custom user-defined subroutine, passing on the note # and channel #. That could trigger game-specific custom actions - TIA drums, AtariVox singing, pokey notes, or even non-sound-related stuff. The value could easily be embedded in the song data by setting one of the DefleMask note parameters that dmf2asm currently ignores.