This is a nice little piece, but ultimately, the optimization could be much better. I'll give a general overview of some stuff I've noticed, and then link an image pinpointing specific examples from the .txt to make it much clearer.
Like with funky-smw, there are a lot of things that are put in loops for no reason; this increases the insert size. As well, certain parts could be looped, but aren't. Following on from this, I don't see any label loops, so I'd strongly suggest using them, as I noticed a few sections that could be looped with the help of them. Just from a quick look-through, channels #0, #1, #2, and #3 could have superloops and label loops, channel #5 could have rests be looped better and some loops merged, and channels #6 and #7 can use a loop and volume fade and have rests looped better. This isn't a comprehensive list, but rather the most prominent things I noticed.
Some commands are also defined redundantly, namely the echo commands. There are several cases of $EF being redefined when it doesn't need to be, as well as one instance of both $EF and $F1 being redefined when neither of them change.
Conversely, I notice there are points where you've used vanilla percussion, having only defined the instrument once. Because of how Addmusic handles vanilla percussion, this causes the samples to detune. For instruments @[email protected], you have to redefine the instrument before each note for them to be correctly tuned. This won't take any extra space unlike with other instrument calls.
As well, there is a section where you used the $ED command with @23; however, this doesn't work correctly either.
This thread explains how vanilla percussion works in-depth.
There are also sections where you've put clusters of the same note repeating, with intermittent volume changes. A better way to do this would be to put all the notes in one loop and then use a volume fade command ($E8 $XX $YY) to increase the volume. Not only does it save space, but it might give a smoother sound, if that's what you want.
Speaking of volume changes, I notice there's one instance of $E1 $00 $80. Because you've set the first parameter as $00, nothing will happen. If you want to change the global volume with no fade, you should use the w command instead. I notice that you haven't defined it at all in your port, which means it will default to w255, the loudest possible. You can redefine w as many times as you wish, just remember that it's a global command. If you want to change the volume of a channel individually, you can use vXXX, which you have. Or, if you want to fade the volume of a channel, you can use $E8 $XX $YY, as I mentioned above.
Here's a visual recap of everything I noticed, along with examples. It's in no way a comprehensive list, but it's hopefully enough to help guide what you should be looking for. I'd suggest giving your .txt a thorough read-through.
Finally, make sure your submission only uses tags from the official tag list on the Submit File page, make sure that your port uses the #SPC tag with the relevant information (more info on this in AddmusicK's readme), and preferably rename your .zip file to something like "Cascades" instead of "Desktop", just for the sake of clarity.
Also, it's worth noting that #option TempoImmunity, in the current version of AddmusicK, does not work. It's up to you whether you want to keep it or not.
Fixing up all these minor issues should make this port ready to go.
bebn legg Discord Manager and SMW Music Moderator Big Bertha
Please read rejection logs more carefully, as a lot of the issues present in your previous submission of this port are still present. Namely, there a lot of redundant/unnecessary hex commands which inflate the insert size, @23 is still used with $ED, there is no #SPC tag, sections that could have volume fades don't, etc. I'd suggest going over the previous rejection log once more.
Now, there are a few things you changed, but a lot of them end up actually increasing the insert size. If you notice, your new submission of the port is actually 0x50 bytes bigger than the old one. This is mainly caused by some of your loops being inefficient and taking up more space than the individual notes; the biggest example of this is looping a single note less than 8 times. In that section specifically, the previous rejection log shows how it could be looped better. As well, there are sections where you could've used label loops, but didn't. Label loops allow you to identify a loop by a number, and then later recall it, so you don't have to redefine note data. They can contain note data as well as hex commands.
Here's an example of how label loops work. Something like this:
Can become this:
As well, don't forget about superloops, which allow you to nest loops.