Language…
5 users online: masl, Nirv, Oskise, playagmes169, Tsquare07 - Guests: 237 - Bots: 258
Users: 64,795 (2,375 active)
Latest user: mathew

Shady Cicada - Push On! by Sheeplover1011

File Name: Shady Cicada - Push On!
Submitted: by Sheeplover1011
Authors: Sheeplover1011
Insert Size: 0x029D bytes
Type: Misc.
Sample Usage: None
Source: Port
Duration: 1:06
Featured: No
Description: A very calm song (until the percussion section), could be used for game overs.

SPC

First saying, this is a very nice attempt. It starts off pretty good, but a couple big issues pop out as it progresses, which should be fixed before this gets approved.

To start, you could do a few things to improve the mixing and make this port even more accurate to its source. In the original, some of the instruments are stereo panned; that means one side of the speakers is louder than the other one, and in AMK, you can create that effect with the y command. In your port, #1 should be panned somewhat to the left, and #2, to the right. Also, the square waves in the original have vibrato in them, an effect that creates pitch oscillation, which's done with the p command. If you have any questions regarding these commands, make sure to take a look at the AMK readme. It explains a ton of useful commands that might help you a lot when porting.

In terms of note accuracy, this port seems rather solid overall. However, you're missing some harmonies and chorded notes the original song has in it, making it so the port feels much emptier compared to its source. Can't tell if you ported based on a midi or did it by ear, but if you listen thoroughly to the song, you can spot those background harmonies going on. For instance, in 0:06 and 0:24, there's a sine wave section in the background, and further along, there's a choir section in 0:38 which has quite a bit of presence in the song. You still have room for those notes, so it'd be great if you did them in the port.

Moving on, I have a few more complaints about what you already have. Firstly, the port's tempo is a bit too high, which means it plays faster than the original; a value around t61 for it would suffice. Second, in every line of #1 and in #3, there's an unneeded < that makes the c1 notes after them to play an octave too low. Third, the @8 bass is too quiet, and it should play an octave lower.

There are some problems regarding the percussion aswell. The most evident one is that both the kick and the hi-hat play higher pitches at times. This occurs because AMK handles with vanilla percussion in a different way, where you need to call the instrument before every note played. Otherwise, it'll unintendedly play higher pitches. Speaking of the hi-hat, it has some issues on its own too. There's an unneeded rest inside the loop which pushes the channel back and, consequently, makes it desync with the other channels (the fourth r16 shouldn't be in there). Also, its volume is a bit too loud, especially when it plays the proper pitch.

Even though the insert size comes fairly low here, the optimization could be more refined overall. You might want to loop the long rest strings you have in the last four channels, as doing so will save a considerable amount of bytes (note that you actually save more space if you loop r2s instead of r1s). Additionally, there are a few note patterns that come back later on, which you could re-call using label loops. In other words, a label loop consists in assigning a number to a loop, so you can call it back later with the number you've set. Or else, you may use the * symbol to call the last loop used in the txt. For example, in #0, you have the following:
Code
f < a > c f e c < a > d+ d c < a g a1 > a f c > c < a+ a f e d e f a c1 < a+ > c d f e d c e f1
f < a > c f e c < a > d+ d c < a g a1 > a f c > c < a+ a f e d e f a c1 < a+ > c d f e d c e f1^1 >

As you can see, these lines are almost the exact same, except for their very last note. That said, you may label the repeating part and call it back later on. In practice, it'd become this:
Code
(1)[f < a > c f e c < a > d+ d c < a g a1 > a f c > c < a+ a f e d e f a c1 < a+ > c d f e d c e] f1
(1) f1^1

If using the *, it'd look like this:
Code
[f < a > c f e c < a > d+ d c < a g a1 > a f c > c < a+ a f e d e f a c1 < a+ > c d f e d c e] f1
* f1^1

Since we're at it, one last note on optimization: it's kinda pointless to loop all the notes after the / twice, since they're already going to be repeated as soon as the song reaches the loop point, and doing so will only increase the memory usage unnecessarily.

Lastly, I have something to clarify. You've tagged the submission as "game over", yet the port doesn't fit for that purpose in a technical way. While it can still be inserted as a global song, it'll consume a lot of space, which can become a problem considering globals are stored in ARAM. Not only that, but it also lasts much longer than the game over screen does ingame. An alternative for that would be including a shorter version of the port, intended to be used globally, but that's up to you.

That should be all. I know I've pointed out a lot of issues here, but most of them aren't really difficult to deal with, so I encourage you to try fixing things up and eventually resubmit the port. Either way, great job with this so far, it's almost there!