Language…
17 users online:  AmperSam, Cardioid, crocodileman94, CroNo, DanMario24YT, Dark Prince, Green, Green Jerry, GRIMMKIN, mtheordinarygamer, RPG Hacker, Rykon-V73,  Shoujo, Skewer, SMW Magic, W3aper, Zavok - Guests: 291 - Bots: 513
Users: 64,795 (2,373 active)
Latest user: mathew

AddmusicK

Tool

First off I have to say, I absolutely love this tool! Thanks for all of your work on this incredible program!

I had a quick question about future implementations of more features within AMK. Would it one day possible to support the removal of older Addmusic programs from Super Mario World hacks that use tools such as such as Carol's Addmusic, Romi's Addmusic, Java Addmusic, etc in order to fix music breaks that occur in accurate emulators with these hacks as the program seems to reject it whenever I try to insert music into hacks that use these tools?

Just a suggestion, keep up the amazing work! #tb{^V^}
Thanks for that.

Looks like:
Pastel Wind-
CHANNEL 0 SIZE: 0x0185
CHANNEL 1 SIZE: 0x010B
CHANNEL 2 SIZE: 0x01FD
CHANNEL 3 SIZE: 0x015F
CHANNEL 4 SIZE: 0x00D4
CHANNEL 5 SIZE: 0x0109
CHANNEL 6 SIZE: 0x0163
CHANNEL 7 SIZE: 0x00E4
LOOP DATA SIZE: 0x01F0
POINTERS AND INSTRUMENTS SIZE: 0x0070
SAMPLES SIZE: 0x661C
ECHO SIZE: 0x2800
SONG TOTAL DATA SIZE: 0x0C70
FREE ARAM (APPROXIMATE): 0x6126

Hot Damned-
CHANNEL 0 SIZE: 0x01DA
CHANNEL 1 SIZE: 0x0161
CHANNEL 2 SIZE: 0x0246
CHANNEL 3 SIZE: 0x019D
CHANNEL 4 SIZE: 0x0217
CHANNEL 5 SIZE: 0x00C5
CHANNEL 6 SIZE: 0x0256
CHANNEL 7 SIZE: 0x0088
LOOP DATA SIZE: 0x09BC
POINTERS AND INSTRUMENTS SIZE: 0x0160
SAMPLES SIZE: 0xB4B9
ECHO SIZE: 0x0800
SONG TOTAL DATA SIZE: 0x17F4
FREE ARAM (APPROXIMATE): 0x2705

Culture Shock-
CHANNEL 0 SIZE: 0x00E0
CHANNEL 1 SIZE: 0x00C0
CHANNEL 2 SIZE: 0x0084
CHANNEL 3 SIZE: 0x00A8
CHANNEL 4 SIZE: 0x0029
CHANNEL 5 SIZE: 0x00C5
CHANNEL 6 SIZE: 0x0073
CHANNEL 7 SIZE: 0x0047
LOOP DATA SIZE: 0x0396
POINTERS AND INSTRUMENTS SIZE: 0x004C
SAMPLES SIZE: 0xB260
ECHO SIZE: 0x1800
SONG TOTAL DATA SIZE: 0x0856
FREE ARAM (APPROXIMATE): 0x28FC

Interestingly, Culture Shock is a bit smaller than Pastel Wind, but leaves half as much leftover ARAM for some reason...
Let's milk Sunny Milk. Then she'll have enough money to fund Sunny Milk Real Estate.
Everypony's digging with a shovel
That's because Pastel Wind, while using many unique patterns (i.e. hard to loop), uses mostly SMW samples with some other, smaller samples whereas Culture Shock, a song with many repeating patterns (i.e. easier too loop), uses purely default Windows MIDI samples and they add quite a bit to their size (so big and may that some vanilla samples have to be removed too). In fact, the song size is nothing compared to the samples so it's usually the latter and echo which causes ARAM shortage, not the song.
I guess it's been a while since I asked this (about three - four months ago, maybe), but a bank border error shows up for roms 4mb or over (SA-1). When will this get fixed?

LINKS -> YouTube - Discord - Twitter

was the -sfxdump command line argument removed for some reason? it's missing from -? (there's an unusual amount of whitespace above -norom plus a missing linebreak between -norom and -?) and it doesn't recognize it as valid, despite being in the readme and there being no other way to dump sfx (to my knowledge, at least).
Quote from my comment on the submission page.
Originally posted by MANGOMILK
Trying to run the gui application via Wine gives me the following error (it's a long one):

I assume the solution is to just use the program via the command line?

(edit) Doing that only inserts the global songs and doesn't generate any SPCs, which I find exceedingly strange

tldr, it doesn't work in Wine. Any chance of a Linux build (or advice on how to build it myself)?
Originally posted by MANGOMILK
tldr, it doesn't work in Wine. Any chance of a Linux build (or advice on how to build it myself)?

I too have interest in this topic, as I'm looking into changing my os from Windows to Linux. So if there is a chance for a version in Linux I'd be glad to hear about it.
                                                                                                                  
                              
It's written in C#, right? Did you try it in mono instead of wine?
I had never heard of mono lol. (I only switched to Linux around a month ago) I'll try that, thanks.

(Edit) Yeah, the GUI works in Mono, but it doesn't appear to know how to start the actual AMK program from there. That one only runs in Wine and not Mono so I think there's a conflict on that end? idk

(Edit 2) Nevermind, it appears the error I get when hitting "run" is related to process creation permissions not being present. The error it gave me tells me the commands I can use to run AddmusicK.exe via the command line, however, and now I can port songs! (Hopefully also insert them but I haven't tested that yet, I was using porter mode in the gui)
The other thing to try is using winetricks to install the .net framework and then run it in wine again.
My attempt to do that failed. But again, my issue with Mono was about AMKGUI not having permissions to create a process for the main AMK executable. (Wine-Mono doesn't work btw)

(E) I was able to create a bash script for what I needed, however I would much rather use the program as intended.
Originally posted by MercuryPenny
was the -sfxdump command line argument removed for some reason? it's missing from -? (there's an unusual amount of whitespace above -norom plus a missing linebreak between -norom and -?) and it doesn't recognize it as valid, despite being in the readme and there being no other way to dump sfx (to my knowledge, at least).

for some stupid reason, the readme says it's -sfxdump even though it's -dumpsfx
Hello everyone! I've got something I need to resolve before my fork of AddmusicK (AddmusicKFF) can go to AddmusicK 1.0.9. It involves a modification to the parser I made towards the beginning of the fork's life.

The feature:
The ability to use = after a l command, as well as dotted notes after any exact tick note. I implemented this into my fork as one of the first additions to my fork: the original commit was done on 12/23/20.

The problem:
This is not compatible with substitution due to its internal mechanism. Specifically, it works only at the start of each character as a command in general, and does not account for characters in between. The dotted note support on exact tick lengths opens an edge case where this happens. Thus, keeping this as-is is technically a breaking change on all past AddmusicK versions.

My current options...
  • Remove this feature, no new parser version
    Basically revert my changes made in this particular case.
    Advantages:
    • Complete compatibility with parser version 2

    Disadvantages:
    • The feature will simply be pushed out to some future release, and my fork will have an incompatibility with this. Plus, I myself actually intended to add this on in the first place.
    • Blind to older AddmusicK versions for other parser bugfixes and modifications (the other parser modifications are to reflect the addition of any hex commands ($FD/$FE and bitwise hot patches), a bugfix when not using #0 at all, a fix when using o after a $DD command for a target octave, and complete uppercase/lowercase support)

  • Add a parser flag, no new parser version
    I will create two new parser flags, #exactdefaultlengthmods and #noexactdefaultlengthmods.
    Advantages:
    • Parser becomes more user-modifiable (and thus allows users that want some older parser quirks to carry them over, though eventually they will require a minimum parser version number to account for changes between AddmusicK versions over time, at least in theory)

    Disadvantages:
    • Blind to older AddmusicK versions for other parser bugfixes and modifications (the other parser modifications are to reflect the addition of any hex commands ($FD/$FE and bitwise hot patches), a bugfix when not using #0 at all, a fix when using o after a $DD command for a target octave, and complete uppercase/lowercase support)

  • Add a new parser version, #amk 3
    Update the parser version to 3. All subsequent parser revisions can acquire this new feature.
    Advantages:
    • Warnings can be created for all parser bugfixes being used in #amk 2 and earlier. This specifically involves using o after a $DD command for a target octave, and using uppercase letters as notes. Not using #0 at all is a little bit outside the scope.
    • Parser flags are still an option if needed, though I will consider this parser version to be the minimum requirement.
    • Hot patch VCMD can incorporate my fixes by default without breaking older AddmusicK songs

    Disadvantages:
    • Overwrites Codec's AddmusicK 1.1.0 beta. Specifically, it overwrites its usage of #amk 3. All .txt files created with this one will be pushed off to a future version of AddmusicK, and either a new flag or a new parser version will have to be reserved. The beta itself has source available except for the C++ side. I have privately acquired this for future adaptation.

  • Add a new parser version, #amk 4
    Update the parser version to 4. All subsequent parser revisions can acquire this new feature.
    Advantages:
    • Warnings can be created for all parser bugfixes being used in #amk 2 and earlier. This specifically involves using o after a $DD command for a target octave, and using uppercase letters as notes. Not using #0 at all is a little bit outside the scope.
    • Parser flags are still an option if needed, though I will consider this parser version to be the minimum requirement.
    • Hot patch VCMD can incorporate my fixes by default without breaking older AddmusicK songs

    Disadvantages:
    • Jumps over Codec's AddmusicK 1.1.0 beta. Specifically, it jumps over #amk 3, which this beta occupied. All .txt files created with this one will be pushed off to a future version of AddmusicK, with the parser version indicated as incompatible for now. The beta itself has source available except for the C++ side. I have privately acquired this for future adaptation.


I'm looking for some feedback on what the best approach to this is, as I am otherwise near the finish line: the hot patch VCMD is the last thing that is being implemented that will both account for playback inconsistencies between Addmusics and also allow me to fix up some quirks without breaking other Addmusic songs that abuse bugs that were previously present.
Using the new parser flag as:
Code
#AMK 4

can be useful. It is currently unused as far as I know!
my thinking is you would ideally support everything you can from that 1.1.0 beta and then release your version with #amk 4, only downside i see there is people getting confused on the naming schemes. maybe you could release yours as 1.1.1 or 1.2.0? though, i also don't know how difficult it'd be to integrate those changes since i'm not personally familiar enough with any amk release to know what's different and what may be difficult to implement
Sadly, I don't feel like I should do that for filesize reasons on the SPC700 side (citing new hex commands specifically: I myself ended up minimizing the ones that made the final cut: namely, two restorations, one of which was functional in vanilla SMW, and the hot patch VCMD, which allows me to perform music bugfixes without breaking playback on older Addmusic songs. In addition, I documented the historical ones as well as their ARAM maps and traced each one versioning-wise.).

I'm not planning on including all of the SPC700-side modifications from Codec's fork at this moment, as I came up with a lot of new SPC700 code in the process of doing noise conflict resolution between SFX and music (previously there was none), the hot patch VCMD (which allows music playback inconsistencies between Addmusics to be replicated while I can still do fixes on the fly), and enchanted readahead to account for loops and superloops (which is part of the initial set of patches I did for the hot patch VCMD). Those were combined with a whole host of code optimizations and bugfixes, one of which had me replace the SFX processing for 1DFA SFX IDs $01 and $04 in the long run with some SFX sequence data instead (though the originals are there for historical reasons, and these are allocated separately).

The last thing I need to do at this point is implant too many features too early without code filtering, and I'm saving VCMD code filtering for past this release (it's also why I'm in a de-facto feature freeze, especially on the SPC700 side).

Also, it's taken me a year to get to this point, and admittedly I want to get a version released (otherwise you'd get AddmusicFR before the update ever happens, and that one completely replaces the core sound driver, albeit with a different N-SPC/Kankichi-kun variant, but that critically would include the SFX programming in its original state... and I have a bad feeling about failing to release a version before that comes out and essentially becomes the new default Addmusic).

I have declined to use 1.1.0 as a version because it has less features than what Codec's 1.1.0 beta had, and I'm going off in my own direction anyways in some ways.

With regards to Codec's AddmusicK 1.1.0 beta... I would have to implement the music syntax specifically, and it also has a few new hex commands, and that new syntax actually converts to those commands. In my fork, when I get there, they will be manually converted due to initially not accounting for them... and on loop breaks, I have a grander plan for them, since there are more than one type of loop break I can do, one of which I can auto-detect if done correctly.
THREAD CLOSE OMG THIS IS FROM 2013 HOW IS THIS NOT CLOSED#smw{>:|}

Tool