Idioma…
14 usuários online: Bullymario, Hayashi Neru, Lane, LightAligns,  MarioFanGamer, mmmdoggy, MrDeePay, nicolascrafter, NikSik1, OnlySpaghettiCode, Romano338, SFan, SolveForX, SoSure - Visitantes: 76 - Bots: 305
Usuários: 55.720 (2.334 ativos)
Último usuário: taste1122

🎶 AddMusicFR - The Flashy Reveal... 🎶

ToolWork in Progress

  • Páginas:
  • 1
  • 2
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.
WITCHCRAFT!

Now if we can't wait to see more of ze progress real soon. This custom music inserter looks very promising!
Panty and Stocking—and Pop Team Epic, evidently—are coming back. Once again. Yes, I'm counting on you. 『いけいけ団長、頑張れ頑張れ団長!』
Help us raise funds for the Armed Forces of Ukraine. #ДопомагаємоРазом / #HelpTogether
“Even if you personally are so dissatisfied with life that you want the world to end, surely the cruel reality is that it will continue on, unchanging. All the better for someone perfectly content, like me.”
Aya Shameimaru, Touhou Suzunaan ~ Forbidden Scrollery
Originally posted by exodustx0
I'm sad to see you're keeping hex commands, as Addmusic should never have had that raw syntax exposed in the first place (makes changing engines in updates without ruining backwards compatibility imopssible after a certain point, effectively requiring an entire new tool all over again... nobody wants this). Other than that though, I'm happy to see so many people putting in a great effort to improve on Addmusic's legacy!


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.
Legacy ports zip (now that those went down because Dropbox)
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.

Originally posted by exodustx0
I'm sad to see you're keeping hex commands, as Addmusic should never have had that raw syntax exposed in the first place (makes changing engines in updates without ruining backwards compatibility imopssible after a certain point, effectively requiring an entire new tool all over again... nobody wants this). Other than that though, I'm happy to see so many people putting in a great effort to improve on Addmusic's legacy!

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.

Originally posted by xfix
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'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.
Originally posted by xfix
Originally posted by exodustx0
I'm sad to see you're keeping hex commands, as Addmusic should never have had that raw syntax exposed in the first place (makes changing engines in updates without ruining backwards compatibility imopssible after a certain point, effectively requiring an entire new tool all over again... nobody wants this). Other than that though, I'm happy to see so many people putting in a great effort to improve on Addmusic's legacy!


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.

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.

Originally posted by LMPuny
Please note that the post indeed says the parser contains new syntax for some commands

Definitely a yikes on my part, my apologies. I was too quick to jump the gun #fim{=_=}

Originally posted by LMPuny
Originally posted by exodustx0
Please... please tell me, does it parse with AST (abstract syntax tree)?


maybe

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 #fim{:B}
Fantastic work. The increase in loop layers cap is a welcome addition. Looking forward to the release.
Wow, this sure sounds like quite the fruitful undertaking... I know I'm definitely looking forward to the updates made to the existing commands, as well as the panbrello and other QOL things. To say nothing of the beautiful ports y'all made with it as well, too. Definitely something I'll have my eye on, even if I still don't fully understand it.
  • Páginas:
  • 1
  • 2

ToolWork in Progress