16 users online:  Ahrion, Alfombra de madera,  AmperSam, El Cuh Fermin, fanfan21, floatybug, Hammerer, kopovision, mariofreak4500, MegaMarioMan9, Pink Gold Peach, redstoneblock, Sarcose, TooMuchOfEverything, Tulip Time Scholarship Games, xhsdf - Guests: 741 - Bots: 346
Users: 66,008 (2,154 active)
Latest user: chiefrunningwolf2001

AddMusicKFF - A fork of AddMusicK (Last updated 6/5/24)


Hello, everybody! This is KungFuFurby, SNES musician, and I've been working on what I technically call a fork of AddMusicK, called AddMusicKFF. This thread is a continuation of the Winter C3 2021 thread.

I have also made a Summer C3 2021 update thread that contains a summary of the progress made here, as well as some info on an AddmusicK 1.0.9 release candidate that was revealed there.

A second update thread was made for Winter C3 2022.

A third update thread was made for Summer C3 2022.

A fourth update thread was made for Winter C3 2023.

A fifth update thread was made for Summer C3 2023.

A sixth update thread was made for Winter C3 2024.

AddmusicK 1.0.9 was finalized on 10/5/23 with its approval by moderation as the next release of AddmusicK after having frozen most updates on 7/25/23.
AddmusicK 1.0.10 was finalized on 2/25/24.

What is AddMusicKFF?

AddMusicKFF is a fork of AddMusicK by Kipernal. I'm not bumping the version number unlike the others due to me having seen two past cases of doing so, and me admittedly realizing that I don't want to join the conflict myself. Plus, I'm intending on maintaining backward compatibility with the older Addmusics.
This actually originated when I created a slowdown fix for AddMusicK for Super Mario All-Stars + Super Mario World that got officially implemented in the standalone version on Super Mario World, debuting on 1.0.7. I also implemented fades to any volume for compatibility for Super Mario All-Stars and the original ID is backward compatible with Super Mario World (that hasn't been ported over yet partially because on the 65816 end, I introduce a conflict past 128 songs, and partially because that code can be improved somewhat by utilizing unused memory locations).

What have you already done?

What are you planning to do?

  • Add actual phrase support. I recorded my proposal on how to implement it here.
  • Consolidate the two jump SFX instances into one pointer-wise. Due to being in two different collections, this requires that I modify the C++ code.
  • Add music/song groups. Just have to work this one out to ensure that they all load correctly and make sure that the same song in multiple groups can be handled properly. (Thanks  imamelia for the request!)
  • Plenty more... just got to figure out which ones to go for.

What quirks/possible bugs do you know about?

I suspect that these were done by design in the original program, meaning I don't have as many plans to change the code to correct these quirks. However, they are documented since they're "gotcha" cases. In addition, in some of these cases, I can't repair these quirks without updating the parser version, because they would break previous songs.
  • The readahead code, when accounting for subroutines and loop sections, has exposed a potential conflict between the instrument set command, the rest command, and the type 3 remote control event due to a failure to fire the KOFF register. Namely, $DA ?? $C7 with remote control event type 3 active causes remote control event type 3 to fire, followed one tempo tick afterwards by the instrument setup routine. Unusual... I have determined that without the type 3 remote control event factoring in that this is done by design, since normally the KOFF register fires first when the rest goes off, thus allowing for a better transition to the next instrument. (Thanks Masterlink for providing me with an example!)
  • The parser does macro substitutions immediately after the $ character, meaning trying to utilize raw hex-like numbers as a macro substitution will conflict with this particular instance. (Thanks brickblock369 for providing me with an example!)
  • If your macro substitution definition begins with an r or a ^, then if the last note is the same character as the first character of a macro substitution, then the substitution will fail because AddmusicK combines rests and ties, thus accidentally filtering out the first character. Note that this also goes across spaces and lines! Note that this is a quirk for AddmusicK's parser only: it is noted as a potential conversion bug from AddmusicM, which also supported substitutions, but did the substitutions before parsing any of the notes, whereas AddmusicK parses them on the fly. (Thanks Anas for providing me with an example and Masterlink for notifying me about this!)

What bugs do you know about and are planning to fix?

See the Github issues list.

Do you have compiled binaries?

You can find the latest compiled binary for Windows here. (Thanks  Atari2.0 for setting this up and hosting the binary!)
As of 2/7/21, two files are available:
  • - Contains the latest version containing all merged changes.
  • - Contains the majority, if not all unmerged changes, for those that want a more bleeding edge experience with the program (and if you want to catch some bugs in the process caused by my changes). The branch that contains all of these changes that I have merged into this package is called bleeding-edge.
The SPCs and stats folder were not properly included prior to 3/20/21 due to being empty on distribution, and thus being excluded from the git repository. This has been resolved via a stub file being created in those folders, thus allowing them to be included by default again as an "empty" directory. (Thanks codfish1002 for notifying me of this!)

All builds as of 3/25/21 contain asar 1.81 instead of 1.71.
As of 5/22/22, the main AddmusicK command line binary is now automatically compiled through MinGW-w64, citing a problem with the build produced by Visual Studio 2019 regarding characters not being properly processed and an off-by-one error on the AMK version detection. After fixing a memory leak and an out-of-bounds error, on 5/24/22, I restored the Visual Studio 2019 build as AddmusicKVS2019.exe for comparison purposes. Still working out the kinks,
but you can compare the two! After all, stability is key!
(Thanks Anas, Masterlink and  Anorakun for notifying me that the Visual Studio 2019 builds were malfunctioning!)
The Appveyor script was changed on 6/4/23 due to an update in the website's security hosting the builds.
The outermost layer folder was missing prior to 8/28/23 due to a mistake in the zip creation process omitting this detail, and instead all of the folders were included individually causing zip extraction processes to sometimes put them all out without an enclosing folder. (Thanks werneta for notifying me about this!)
As of 9/9/23, asar.dll is now included along with the .exe file, since if it can be run, overall execution is faster and warnings won't be output. (Thanks  Atari2.0 for requesting this!)

There are two new builds that are currently being concurrently updated with the master branch after having been created at the start of Summer C3 2021:
  • is the latest release candidate build for AddmusicK 1.0.9. A special AddmusicK1.0.9 branch, branched off of the master branch, was created especially for this occasion. This branch is no longer being updated with the finalization of AddmusicK 1.0.9 on 10/5/23.
  • is like the above build. Initially, it was designed to include all four of the changes that might require some remoderation (and thus was stored in the AddmusicK1.0.9bleeding-edge branch) as indicated in the Summer 2021 C3 thread, as well as also include the remote gain/anticipation gain restoration, which was affected by one of the issues mentioned above. That usage was obsoleted by the addition of the hot patch VCMD. It may contain some testing material for new stuff intended to be added on to 1.0.9, but ever since I merged in both the hot patch VCMD and remote gain/anticipation gain restorations, this branch is basically identical to the standard release candidate. It does not contain other bleeding-edge branch changes either. This branch is no longer being updated with the finalization of AddmusicK 1.0.9 on 10/5/23.

This build was first created on 10/20/23 in preparation for setting it up as a prerelease candidate:
  • is the latest release candidate build for AddmusicK 1.0.10. A special AddmusicK1.0.10 branch, branched off of the master branch, was created especially for this occasion.

As of 1/11/24, there is now a bleeding-edge variant of the above build:
  • is like the above build, but it is based off of the AddmusicK1.0.10bleeding-edge branch, which has some things that are planned to, but are not quite ready to be included in the release candidate. Please note that they may have some quirks and/or safety issues to iron out.

View the project here on Github

Note that I recommend updating Asar to version 1.81. The version currently included in the Github repository is 1.81, whereas the version included in a stock AddMusicK build is internally identified as v1.33, which is older than the oldest surviving version hosted on this website!

The makefile was adapted from HertzDevil's fork of AddMusicK, since one didn't exist before.
 KungFuFurby why a fork#smw{o_O?}
I forked it in the first place because I was initially going to make some new things that I knew weren't going to make the initial cut into AddmusicK. However... I think  LadiesMan217 realized very early on what this was going to become... as far back as when I first compiled AddmusicK on November 15, 2020 on the old Intel Mac.

The above post is getting huge, so I'll post all of the changes that made it into the release here:

What is included in AddmusicK 1.0.9?

What is included in AddmusicK 1.0.10?