Banner
The Overworld Design Contest ends in
1 MONTH, 3 DAYS, 6 HOURS, 55 MINUTES AND 41 SECONDS
Views: 898,115,205
Time:
12 users online: AmperSam, Carld923, Cheolpeoduck, Koopster, Lpoool, MercuryPenny, pixelninetales, Ralshi02, SAMYR DUTRA ARAUJO, SKKiro, Tony.Metcalfe, UltiMario - Guests: 61 - Bots: 146 Users: 50,398 (2,288 active)
Latest: cs3790151
Tip: If you plan on making long levels, be sure to include multiple midway points.
Not logged in.
AddmusicK v2.00 - In Progress!
Forum Index - SMW Hacking - Resource & Tool Releases - AddmusicK v2.00 - In Progress!
Pages: « 1 2 » Link
♫ AddmusicK v2.00 ♪

Hello everyone! I am working on a new version of AMK.
This is a big update that adds new commands, new labels and corrects some errors.

I am aware that if this tool is aceppted for SMW Central, all the songs hosted here will have to be updated.


() → Done
() → Working on it

Here is a list of what I have done and am doing:

• [] The SPC700 code has been rewritten in order to removing a LOT of unnecessary code and adding definies for all addresses;

• [] Rewrite the "patch.asm, patch2.asm and tweaks.asm" files;

• [] Port all SMW songs;

• [] Add support to MSU-1;

• [] Update to Asar 1.71;

• [] Command $E6 will return to "Tremolo Off" as the original. (The subloop command still remains but as another number);

• [] Remaped the percussion command $D0-$D8 to $C8-$D0;

• [] Fixed an issue where percussion on channels #6 and #7 stopped playing after SFX;

• [] The "author" tag of the SPC information will be renamed "Artist";

• [] The "Get Echo Buffer" code was simplified. Now the songs are loaded some milliseconds more faster;

• [] Removed the compatibility with old addmusic's (AMM/AM4);

• [] Removed the tags: #amk, #am4, #amm, #option, #tempoimmunity, #noloop, #halvetempo, #dividetempo, #smwvtable and #nspcvtable;

• [] Changed channel definition to #Track(X). Where "X" is the channel number (1-8);

• [] Added three FIR Filters most used by SNES games:
Code
$58,$BF,$DB,$F0,$FE,$07,$0C,$0C
$0C,$21,$2B,$2B,$13,$FE,$F3,$F9
$34,$33,$00,$D9,$E5,$01,$FC,$EB


New commands:
Check out a map below that shows how the commands will look:


New commands:
• [] Echo Delay Fade
• [] Echo Feedback Fade
• [] Pitch Envelope Off
• [] Arpeggio Off
• [] Remote Command Off
• [] Pitch Modulation Toggle
• [] Echo Channels
• [] Set Left & Right Volume
• [] Loop Break
• [] Subloop Break

New Labels:
• [] sXX(YZZ) → $YY $XX $ZZ (Fade command)
• Eg1: $E1 $5A $FA → s5A(w250)
• Eg2: $DC $18 $14 → s18(y20)
• Eg3: $EA $25 → s25(p)

• [] Ad ($XX $YY) → ADSR ($ED $XX $YY)
• Eg1: $ED $4F $E0 → Ad($CF $E0)
• Eg2: $ED $72 $AA → Ad($F2 $AA)

• [] Ga (XX $YY) → GAIN ($ED $80 $YY). Where "XX" is the acronym for the type of GAIN you want to use (Di, De, Ex, In or Be)
• Eg1: $ED $80 $BA → Ga(Ex $1A)
• Eg2: $ED $80 $FE → Ga(Be $1E)
• Eg3: $ED $80 $40 → Ga(Di $40)

• [] tuning[XX]=Y → Tuning(@XX) = Y
• Eg1: tuning[2]=-1 → Tuning(@2) = -1
• Eg2: tuning[15]=5 → Tuning(@15) = 5

• [] $DD $XX $YY $ZZ → &($XX note+length)
• Eg1: $DD $02 $18 $A1 → &($02 o3 a8)
• Eg2: $DD $5A $36 >>a+ → &($5A >>a+4^32)
• Eg3: $DD $00 $D8 $BE → &(o6 d1^8)

• [] k -> Set percussion
Note: percussion is not a $DA command. So it will be moved "@21- @29" to "k1-k9". As a result, custom instruments will start from "@20" instead of "@30".

Removed commands:
• Boost Volume ($FA $03 $XX) (obsolete by the new "Set Left & Right Volume" command)
• Set GAIN ($FA $01 $XX) (obsolete by the old $ED command)
• Data Send ($F9 $XX $YY) (Nobody use this)



I would like to hear your opinion on these changes, as well as new ideas.
Soon i will send the tool link.

Note: I am not a professional programmer so there may be things that I may not be able to do.
This is a surprise. I hope the tool design/coding goes well. Some things:

Perhaps you could add "dumper" to the SPC tags?

Do you think it would be worth adding a command to set custom percussion, i.e., replacing the data used for $C8-$D0 with custom parameters in the current track?

Why isn't the shorthand for $F7 $09 just !9?

Quote
Changed channel definition to #Track(X). Where "X" is the channel number (1-8);

I mean, okay, but why is this necessary?

Quote
• Data Send ($F9 $XX $YY) (Nobody use this)

Actually, that's not true. It's been used to let the SNES know what part of the song is playing for level elements that sync with the music (like the beat block levels in Super Mario 3D World). I think SMWCP2 had a level like that, and I had plans for the same thing.

Now, there are at least two other inclusions I'd like to see:
- Track batching. This would allow for multiple tracks to be in ARAM at once, so switching between them would take essentially no time. Presumably, the samples would be the same for all of them. This would mainly be useful for having different variants of miscellaneous songs, like how Donkey Kong Country 2 has a different death theme for each level track.
- The ability to play different parts of a track and enable/disable commands depending on data that the SNES sends to the SPC. This would be good for levels like the circus levels in SM3DW, where the level music would only advance to the next part once you cleared the current section of the level, or making the music echo or have extra channels when you're underwater, for instance.

Also, if this is such a big rewrite, is it really even AddmusicK still? How much of Kipernal's code are you keeping?
Yay! Nice to see some more work on this!

Especially seeing the "remote command off" being intended to work, as it's annoying to see remote commands taking priority over the non-remote commands and therefore having to rewrite those commands as remote.
Nice to see some progress on this! Sadly I'm not someone who can really port music nor am I really interested in the technical details about how it works, but I can't wait to see more progress on this.
I really don't know if this was an addmusic issue or not I just know it happens when you use addmusic on a rom, but with this new version is it possible to fix the singular extra note that happens during the bonus game while using the vanilla music.

--------------------
Your layout has been removed.
That's quite interesting. Given that AMK lacked major development. Having more command aliases to hex command looks really helpful too as it potentially allows for more cross compatibility.

I also find it interesting that a lot of commands (from $C6 to $D9) are all unused in AMK.

Originally posted by imamelia
Quote
Changed channel definition to #Track(X). Where "X" is the channel number (1-8);

I mean, okay, but why is this necessary?

Seconding this.

Originally posted by imamelia
Quote
• Data Send ($F9 $XX $YY) (Nobody use this)

Actually, that's not true. It's been used to let the SNES know what part of the song is playing for level elements that sync with the music (like the beat block levels in Super Mario 3D World). I think SMWCP2 had a level like that, and I had plans for the same thing.

Other example: Dance the Rachenitsa! from YUMP 2 and Richter's Mixtape (S.N.N. and Medic) from CLDC.

Originally posted by imamelia
The ability to play different parts of a track and enable/disable commands depending on data that the SNES sends to the SPC. This would be good for levels like the circus levels in SM3DW, where the level music would only advance to the next part once you cleared the current section of the level, or making the music echo or have extra channels when you're underwater, for instance.

Also seconding this. In fact, the ability to play patterns (the N-SPC used by other games can do that and is implemented with AddmusicY) would be really useful in general as it allows you to potentially save space aside from being able to specify sections.
Thinking about it... What do you think of the possibility to add code to songs for potentially more control?

--------------------
Okay, my layout looks ugly.
This is pretty surprising! The new commands are quite promising!

However, I'm very hurt that you removed AM4 and AMM compatibility as that's what the point of AMK was at the beginning of its development. Plus, people like me and others might have a bunch of old AMM/4 ports around that they don't have anymore patience or wanna work harder to convert than just slapping the necessary tags and, if necessary, changing the echo delay and redefined label loops alongside other small modifications. I'm also hurt that you removed all the necessary tags for old port compatibility, as well as tags like #halvetempo, #dividetempo, and #tempoimmunity, which, if they don't actually work consistently, can actually be fixed to work. Last but not least, I don't think you should've removed the amplify command, as that's used by quite a few ports. All in all, removing all of these things will break compatibilty and warrant another remoderation, which might not be good. Please add them back in.

On the other hand, why don't you add a command for pulse-width modulation, which was used in the Romancing SaGa trilogy's songs and was actually featured in AMM as well as an obscure command from AMM that allows you to oscillate the waveform of a certain sample (here, it was an external square wave sample that came with AMM and was inserted in slot 0x09 of a text file called 'blist.txt')?

Edit: Sorry if this post was a little too long, but I had a lot of stuff to complain about as well as suggest. I couldn't turn a blind eye at this.

--------------------
My Mode 0 guide.

My Discord server. It has a lot of archived ASM stuff, so check that out!

Originally posted by StackDino
I am aware that if this tool is aceppted for SMW Central, all the songs hosted here will have to be updated.

I can't speak for the music mods but imo a remoderation of this scale is most likely never going to happen: if you want this to be approved and become "the new addmusic", it'll have to be backwards compatible (which doesn't look like you want it to be, since you removed some stuff from AMK and changed a lot of commands numbers and whatnot).
Originally posted by KevinM
Originally posted by StackDino
I am aware that if this tool is aceppted for SMW Central, all the songs hosted here will have to be updated.

I can't speak for the music mods but imo a remoderation of this scale is most likely never going to happen: if you want this to be approved and become "the new addmusic", it'll have to be backwards compatible (which doesn't look like you want it to be, since you removed some stuff from AMK and changed a lot of commands numbers and whatnot).


Very good point. I was so hurt by the removal of AMM/4 removal that I completely missed this. By the way, I think the 'Ga', 'Ad', 'tuning' and 's' commands are pointless. One could could just use the hex commands and define them in macros or, as AMK calls them, replacement commands. Also, I think you shouldn't remove the '$FA $01 $XX' command if for some reason nobody wants to use the #instruments table (after all, choices are choices, even if this one sounds niche, so why even bother its removal?).

--------------------
My Mode 0 guide.

My Discord server. It has a lot of archived ASM stuff, so check that out!

Originally posted by AnasMario130
By the way, I think the 'Ga', 'Ad', 'tuning' and 's' commands are pointless. One could could just use the hex commands and define them in macros or, as AMK calls them, replacement commands.

They're not pointless, having a more user friendly syntax (and not having to use macros everytime) for hex commands is good (besides the fact that 'tuning' already exists in AMK). s also looks neat because it's a generic fade shorthand and you can apply to different commands.

Edit: the point of removing $FA$01$XX is that it does the exact same thing as $ED$80$XX, so it's only a waste of space.
Originally posted by MarioFanGamer
a lot of commands (from $C6 to $D9) are all unused in AMK.

That's false, actually. N-SPC will take all of $C7-CF as rest, and $D0-D9 as percussion notes. $C6 is a tie. AMK didn't change this for its engine, meaning that yes, there are quite some wasted vcmd bytes.

Originally posted by AnasMario130
I think the 'Ga', 'Ad', 'tuning' and 's' commands are pointless. One could could just use the hex commands and define them in macros or, as AMK calls them, replacement commands.

Addmusic should never have used raw hex commands. Once you allow users to write ports with raw hex commands, backwards-compatibility becomes a nightmare. Every time you issue an update, you gotta wade through a lot of "what is what again". Leave the raw hex up to the tool; use dedicated syntax instead. And in the case of AMK and previous Addmusics, in the absence of dedicated syntax: cry.

"s" makes sense to me, especially as unified syntax that's not directly attached to a specific fade (or if you want to have "s" make sense, slide). Instead of having one syntax token per fade type, you can have one "container" syntax token which can then take specific other syntax tokens. Parsing-wise, that's a very elegant solution.
Originally posted by KevinM
Originally posted by AnasMario130
By the way, I think the 'Ga', 'Ad', 'tuning' and 's' commands are pointless. One could could just use the hex commands and define them in macros or, as AMK calls them, replacement commands.

They're not pointless, having a more user friendly syntax (and not having to use macros everytime) for hex commands is good (besides the fact that 'tuning' already exists in AMK). s also looks neat because it's a generic fade shorthand and you can apply to different commands.

Edit: the point of removing $FA$01$XX is that it does the exact same thing as $ED$80$XX, so it's only a waste of space.


Ahhh, okay. Now I get it, especially the syntax part. At first, I personally thought they were pointless, but now I realize it's for cleanliness. Pardon me.

--------------------
My Mode 0 guide.

My Discord server. It has a lot of archived ASM stuff, so check that out!

Originally posted by StackDino
• [] Ad ($XX $YY) → ADSR ($ED $XX $YY)
• Eg1: $ED $4F $E0 → Ad($CF $E0)
• Eg2: $ED $72 $AA → Ad($F2 $AA)

I don't understand why the decay values would need to have 8 added to them. Wouldn't it be better to just type the decay value you want instead of going through, even if simple, an extra math step? I know AMK currently does this for ADSR in #instruments, but as far as I know that's only because that's used to tell the program whether to use ADSR or Gain. Also, this may have disagreements from porters because of years of habit, but maybe it'd be nice to take the opportunity to change the parsing so the values are read in A-D-S-R order instead of D-A-S-R as it has been so far, if only to make it easier for new porters and also to correspond to the order displayed in SPC700 Player.
Originally posted by Exodustx0
Originally posted by MarioFanGamer
a lot of commands (from $C6 to $D9) are all unused in AMK.

That's false, actually. N-SPC will take all of $C7-CF as rest, and $D0-D9 as percussion notes. $C6 is a tie. AMK didn't change this for its engine, meaning that yes, there are quite some wasted vcmd bytes.

Ah, right, I forgot about those. But it's still unused commands.

Originally posted by Lumy
I don't understand why the decay values would need to have 8 added to them. Wouldn't it be better to just type the decay value you want instead of going through, even if simple, an extra math step? I know AMK currently does this for ADSR in #instruments, but as far as I know that's only because that's used to tell the program whether to use ADSR or Gain. Also, this may have disagreements from porters because of years of habit, but maybe it'd be nice to take the opportunity to change the parsing so the values are read in A-D-S-R order instead of D-A-S-R as it has been so far, if only to make it easier for new porters and also to correspond to the order displayed in SPC700 Player.

That's because that's how ADSR works: Each channel has got three bytes for the envelope and if the first byte's hight bit is set (value is greated than $80), it's ADSR, else GAIN (sam reason why you need to add $80 in the instrument definition as the bytes are stored directly). However, since the ADSR and GAIN commands are separate, the function can add or subtract $80 internally whereas the users don't need to care for the high bit. Being able to specify the ADSR settings separately also is useful (and makes more sense, tbh).

@KevinK and @Anas: Good question. Actually, it really depends on how different the syntax is to AMK1 and how much of it can be converted and parsed differently. And besides: Backwards compatibility still can be added later on.

--------------------
Okay, my layout looks ugly.
Originally posted by Lumy
Originally posted by StackDino
• [] Ad ($XX $YY) → ADSR ($ED $XX $YY)
• Eg1: $ED $4F $E0 → Ad($CF $E0)
• Eg2: $ED $72 $AA → Ad($F2 $AA)

I don't understand why the decay values would need to have 8 added to them. Wouldn't it be better to just type the decay value you want instead of going through, even if simple, an extra math step? I know AMK currently does this for ADSR in #instruments, but as far as I know that's only because that's used to tell the program whether to use ADSR or Gain. Also, this may have disagreements from porters because of years of habit, but maybe it'd be nice to take the opportunity to change the parsing so the values are read in A-D-S-R order instead of D-A-S-R as it has been so far, if only to make it easier for new porters and also to correspond to the order displayed in SPC700 Player.

The instrument way of defining ADSR is the technically correct way, since that's how the values are then used in the DSP registers. In fact, I never really understood why the $ED command had to use them differently, I guess it comes from older Addmusics (I know usually other SNES engines have an ADSR command which uses values from $80$00 to $FF$FF). Changing the order of the values in the two bytes is something I would advise against for the same reason: that's the order in which they're used in the DSP registers (i.e., the $DA$SR bytes are directly copied there), so it makes sense for them to be like that.

Edit: and yeah, the SPC then determines if to use ADSR or GAIN based on the $DA byte in the DSP registers: if it's >=$80, then ADSR is used, otherwise GAIN is used. That's why if you write a value of $7F or lower in the $DA register using the direct DSP write (for example, $F6$05$00) it'll change the envelope for that channel to the gain of the instrument instead. Also this is not an Addmusic thing, it's just how the chip works.
Originally posted by KevinM
The instrument way of defining ADSR is the technically correct way, since that's how the values are then used in the DSP registers. In fact, I never really understood why the $ED command had to use them differently, I guess it comes from older Addmusics (I know usually other SNES engines have an ADSR command which uses values from $80$00 to $FF$FF). Changing the order of the values in the two bytes is something I would advise against for the same reason: that's the order in which they're used in the DSP registers (i.e., the $DA$SR bytes are directly copied there), so it makes sense for them to be like that.

Oh, interesting to know it's actually how it's read by the chip, but while keeping the bytes intact keeps things consistent with other engines and the raw code, it doesn't exactly facilitate porting, which should be the goal of a porting tool, especially for those who're not knowledgeable at code level (which is the majority). Also, like MFG said, there are two separate tool commands for ADSR and Gain, so I don't see much of a point in keeping the high byte syntax for ADSR in this case.
A command to disable staccato without using the legato trick (which produces a lot of clicking) would be very appreciated.
Edit: Oh, and since there's independent left and right volumes, is it possible to add the constant fade used in Software Creations' sound engine?

--------------------
През горите, през полята, под звездите, над житата
Originally posted by imamelia
Perhaps you could add "dumper" to the SPC tags?

I thought about adding it, but the one who dumps the SPC's is always the AMK.

Originally posted by imamelia
Why isn't the shorthand for $F7 $09 just !9?

Because it is related to the channel settings. As well as in the "?0" (No Loop command).

Originally posted by imamelia
Quote
• Data Send ($F9 $XX $YY) (Nobody use this)

Actually, that's not true. It's been used to let the SNES know what part of the song is playing for level elements that sync with the music (like the beat block levels in Super Mario 3D World). I think SMWCP2 had a level like that, and I had plans for the same thing.

Ok, I will add it again.

Originally posted by imamelia
- The ability to play different parts of a track and enable/disable commands depending on data that the SNES sends to the SPC. This would be good for levels like the circus levels in SM3DW, where the level music would only advance to the next part once you cleared the current section of the level, or making the music echo or have extra channels when you're underwater, for instance.

It is similar to the "Yoshi Drums" command.
I forgot to mention that I will add a .asm file for anyone who wants to add new functions for communication between SNES and SPC700 ($1DFA). For example: The channel 5 plays if the Mario is underwater.

Originally posted by imamelia
Also, if this is such a big rewrite, is it really even AddmusicK still? How much of Kipernal's code are you keeping?

Most of the code is from loveemu and Kipernal, I added some routines, remaped some addresses, and other things.

Originally posted by Ninja Boy
I really don't know if this was an addmusic issue or not I just know it happens when you use addmusic on a rom, but with this new version is it possible to fix the singular extra note that happens during the bonus game while using the vanilla music.

What happens in the song "Done Bonus Game" is that it uses "/r" instead of "?0".
Don't worry, I will port all songs of SMW.

Originally posted by SiameseTwins
Edit: Oh, and since there's independent left and right volumes, is it possible to add the constant fade used in Software Creations' sound engine?

There are few free RAM addresses for new commands. But I can try.



I removed the AMM/AM4 compatibility so that the tool code is lighter, and so that the code of the song is more standardized.
Note that PIXI is not compatible with Romi's sprite tool.

I think about changing the file extension from .txt to .mml or .mwm (Mario World Music), that way you can distinguish a text file from a music file. What do you think?

Originally posted by StackDino
Originally posted by imamelia
Perhaps you could add "dumper" to the SPC tags?

I thought about adding it, but the one who dumps the SPC's is always the AMK.

You could always add the AMK as dumper.

Originally posted by StackDino
I removed the AMM/AM4 compatibility so that the tool code is lighter, and so that the code of the song is more standardized.

You can have backwards-compatibility and standardized code alongside eachother, in segregated parts of the program.
Originally posted by SiameseTwins
A command to disable staccato without using the legato trick (which produces a lot of clicking) would be very appreciated.

Seconding this. However, I don't think having native support for that in the engine would prevent clicking. It may reduce clicking somewhat depending on how it is done (snesmod does sound a bit cleaner than amk with the legato trick, but snesmod still has its own clicks which can be annoying depending on what you're doing). Still, a simple command to turn on/off stacato wouldn't bloat the insert size the same way the legato trick does in some cases, and it would also decrease slowdown since the legato tricks are basically bruteforcing a feature that isn't native to the engine.

Now to my thoughts on AddmusicK 2.0.

I don't understand why a remote code off command is needed. Doesn't (!x,0) do that already? If you've added a remote code off code in the engine, I'd just say use (!x,0) as an alias for that and move on. No need to make an extra syntax command for it, unless you're completely overhalling how remote codes work or something.

I also feel like a number of things are being changed needlessly. Changeing #x to #trackx just doesn't seem technically efficient.

Same with changing extension to .mml, .mwm etc. Afaik, addmusicK doesn't care what your file extensions actually are. Changing the extension is going to create confusion and extra work for users, particularly new porters, who are going to wonder what magic program they will need to open .mml or .mwm files, who are going to be completely blown away by the fact that Notepad or Notepad++ can open them because they are standard text files. Now those users have to do extra work to set up the file association in Windows, or set filetype in the open dialog to *.* in their text editor when they want to open files. These are certainly doable things, things which I wouldn't have issue with if we started off with odd extensions to begin with, but since the .txt extension is already cemented here, I don't really see the need in changing it now.

I get the impression you want to start over with AddmusicK. To get rid of the things you see as antequated and unnecessary, and to reform it to be what it should have been to begin with? To be honest I can see where you're coming from, so don't think I'm hating your ideas. If this was an independent driver which didn't have such a community following it, I wouldn't be so critical. it's yours, do whatever you like so long as I can use it. As a porter, all I really care about when I'm porting is my experience with the driver. If big changes need to be made, I'm fine so long as I can keep up with them. But I do have to consider the community who will be using my ports. The last thing I want is to have to decide whether I do a port for myself, using the latest and greatest tools, or whether I want to release it using an older tool because migration to the new is too difficult for the mods, romhackers etc.

--------------------
Make more of less, that way you won't make less of more!
Pages: « 1 2 » Link
Forum Index - SMW Hacking - Resource & Tool Releases - AddmusicK v2.00 - In Progress!

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2021 - SMW Central
Legal Information - Privacy Policy - Link To Us


Menu

Follow Us On

  • YouTube
  • Twitch
  • Twitter

Affiliates

  • Super Mario Bros. X Community
  • ROMhacking.net
  • Mario Fan Games Galaxy
  • sm64romhacks