🎶 AddMusicFR - The Flashy Reveal... 🎶

RIP SPC Studio, long live AMFR

I'm curious about possible interoperability with EBMusEd, a dedicated N-SPC tracker that (now, thanks to my instrument packer tool) can work with AMK-style BRR definitions. I think Pinci's been able to get AddMusicYI binaries imported into it.

I would like to point out that there is no rule saying that $ED needs to actually compile to $ED. For instance, if an AddMusic arbitrarily wants to have $42 for ADSR, it could interpret $ED as actually meaning $42.

I did not expect an entirely new addmusic to be released this C3. It's definitively cool to see how much the MML syntax has been improved compared to AMK's (and to an extend, AM4 and AMM as well), particularly the inclusion of non-hex commands but also general improvements to the engine are very cool such as more loop layers, local commands as well as other local data. In fact, local commands might be very helpful to help porting songs from other games such as how they define vibrato and the like.
It's also cool to see patterns, a feature which none of the SMW addmusics ever supported IIRC (or if one did, it's pretty obscure) and some of the new features also sound quite cool.

Small question: Will AMFR support local global songs? Basically, it's how DKC2 and 3 handle its win and miss songs.


To be fair, I see hex commands as ASM (or worse, compiled data) within in C-code. That means, they have their place in some cases but of course, you should avoid them as much as possible which makes them closer to a last resort than something normal.


I'll actually disagree with that one. The purpose of hex commands is to write the data directly as they are into the final data. By introducing remapping, things become a lot more ambiguous. Of course, you can work around that but it's better to avoid that rather than use duct tape for a hacky fix.

time to port the entire tim follin snes library

I haven't looked at the syntax to see how different amk and amfr really are, so my viewpoint is a bit ignorant here. Nevertheless, I feel that you can't have amk compatibility without its hex commands. It's a sad truth. So, I think remapping would be acceptable, but only as a backward compatibility measure for text files made with #amk 2 and the like. Yeah it's not a great solution, but I really don't see another way to nicely work around the issue of what to do with over 5700 entries in the music section. I mean we could have a section for amk and another for amfr, but this would double the workload for the mods, especially if they are working on a submission where someone has offered a version of the txt for both tools. I'd personally be tempted to offer both at least in cases where it seems reasonable.

Atm, I think I'll just patiently wait for amfr to mature. Maybe when it's released/more people play with it, the decision will be easier/more intuitive. I'm hoping that's the case anyway.

---

Make more of less, that way you won't make less of more!

Argument noted... for me, this sound driver's internal hex VCMDs don't match AddmusicK's, even with the IDs that would be internal to AddmusicK in the first place: its VCMD table starts at $D6 instead of $DA.

Might I recommend the #amfr 1 flag for anything created with AddmusicFR (the 1 being your parser version)? It'll make things easier for all of us, since you can now have your own parser to work with rather than try to modify a pre-existing parser version that could be subject to unexpected bugs on both sides that pop up during conversion.

Here's my notes on possible playback differences that don't involve new VCMDs (it's a small list, but still notable):

• Depending on how your instrument code is set up to handle GAIN/ADSR VCMD cases, you could have the same problem as the ADSR/GAIN write order bug that I had (the original one does) because it jumps to the instrument setup code. I fixed that problem for AddmusicKFF, though I have since determined it's going to the hot patch VCMD.
• Readahead is known to account for subroutines, however it doesn't account for exiting and entering multiple subroutines (whereas I do account for that). This doesn't happen in AddmusicK.
• The pitch slide VCMD ($DD on SMW, $EF on FE3) always accounts for per-channel transposition, which doesn't happen on AddmusicK by default.

That's a really quick way to make maintaining the parser a hellish process. A hypothetical Addmusic's devs could do this as much as they like, sure, but they'd be shooting themselves, and anyone trying to learn about the nitty gritty of their Addmusic's internals, in the foot.


Definitely a yikes on my part, my apologies. I was too quick to jump the gun


Having seen a small bit of example bytecode output from Masterlink, consider me mega excited! Can't wait to get my hands on your parser

Fantastic work. The increase in loop layers cap is a welcome addition. Looking forward to the release.