RichterSnipes

i like the way your hacks going

hello

I never actually played 4 swords (what with it requiring 3 other people to play), but in Sappy at least, it plays back significantly crisper.

The main notable thing is that it has half the normal number of ticks per measure (96 as opposed to the midi standard 192).

This is why the tempo value gets halved, and why modulation values need to be halved when porting down from DS or up from GB, because both of those systems work on a 192 tick measure system.

The M4AA engine is very bad at modulation at high speeds (see the utter failure of it to correctly play back the GSC Rocket Hideout as an example).

Finally, it doesn't seem to have any obvious way to control the noise channels, unlike the GB, although it may simply be a case of finding the right conversions, and the engine has nothing to do with it.

Yeah, I noticed the clarity drop in ALTTP as well. Interestingly, ALTTP's sister game (on GBA) Four Swords used the M4AA engine, at least partially.

It might use a completely separate engine. Seems pretty unlikely, since most, but not all, Nintendo games use the M4AA engine.

The quality is probably because the samples are low quality. I can't definitively say that, but that's probably the reason.

What is it?

https://dl.dropboxusercontent.com/u/24219056/ViridianForest.WAV

And as a bonus for no apparent reason:
https://dl.dropboxusercontent.com/u/24219056/KTBO.WAV

As it happens, through debugging I found a set of somewhat random looking numbers accessed whenever the game uses a noise track on GSC. I suspect these numbers may be related to what you're talking about in that they set how the noise track is played.

I haven't yet found the same table on RBY, but through debugging, I should be able to find it.

As to porting it over to the GBA, I don't know. You managed by doing a sort of "by ear" conversion, so perhaps it would be useful to start from there?

Also, I am having severe issues with the modulation in one particular song from gen 2. The Team Rocket hideout has such a high modulation rate (127, the max value!) that the whole note becomes distorted, rather than producing a smooth note like the GBC. Any thoughts?

In theoretical terms, at least, 100% sure. With a delay of 1 and a length of 0, it should produce a note length of 1.

In practical terms, I don't know.

My plan was to have note length just be a decimal value between 1-192, and on compilation, the tool would calculate if a frame delay change was necessary, and if it was, insert the command, followed by the note. I was going to try to hide this complexity from the end users, if at all possible.

From my immediate rationalisation, I worked out that the max values of frame delay and note length would be 0xC and 0xF respectively. These 2 values combined give the maximum note length of 192 in GBC note architecture. This also means every note value in this range is covered.

In terms of other commands, they would take the obvious necessary parameters, it would be up to the too to rationalise them so that they make sense when played back on the GBC.

OK, implemented those changes and I'm getting sensible sounding noises out. If I could just understand and parse the actual noise behaviour (ie, how it chooses what sound it makes), I'd be done.

Oh well, in any case, I'm about to move on to assembly into the Gen 1 and 2 ROMs.
Got any preferred formats for that? I was thinking something that looked a bit like XSE in terms of the music commands (since the music is technically a script, when you think about it).

So an example music command would be:
Note C 4 12 7 1
Where the parameters stand for:
C = Note to play
4 = Octave
12 = Length
7 = Velocity
1 = Fade

The reason for so many parameters is that asking a user to understand the Frame Delay command is asking a bit much, IMO, so if I have it in each note command and parse it correctly, I can add it in on the fly when necessary.

Also, incidentally, brilliant Profile Image! :D

I can tell you that E3 determines the noise pattern on Gen 2, although I'm unsure as to how it actually defines anything, as it points to a bunch of numbers which carry no obvious meaning. As for the rest, I'll see about implementing the changes at least, so that the notes exported make sense.

Well, that pretty much covers the full gauntlet of questions for Gen 1, as (distortion and noise notwithstanding) I seem to have very accurate reproductions of the music coming out now. There are some issues with the rising notes, but I'll look into them more accurately at a later date.

Fair enough, I worked off that assumption, and it seems to be working. Now another question, do you know where the headers for the songs in this region (22330-23F51) are? They're missing from any known list, and they would appear to include the battle themes (given that those are absent from what my tool can export currently).

I have tried to find them, with no luck, so I'm a bit bemused.

Don't suppose you know the "max" value of it? I assume it can't be 0, for obvious reasons, so does it just operate from D1 - DF?

Frame delay defines how long each "tick" of the music actually takes. It's normally set to 0xC, but can be changed to lengthen/shorten a note's duration. With a note length of 0 and a frame delay of 0xC, the note lasts 12 (0xC) frames on a GBC, or W06 on GBA (due to the halving effect).

In GSC, there's a command which directly modifies this frame delay to allow for longer/shorter notes, and I was wondering if there was an analogous command on RBY, since some notes don't play at the correct rate on export with my tool, and I assume that with the systems being so similar, there will be a command which modifies this value somewhere.

I don't suppose you know what the "Frame Delay" command is on Gen 1? It's command 0xD8 on GSC and has a format of D8 [Frame Delay] [Note Volume].

The other question has to be what does command E8 in RB and presumably Y do? It doesn't appear to actually take any parameters, so it's somewhat confusing. It's just there...

Ah, it turns out the off notes are caused by incorrect note alignment in the definitions.ini.

VG = VoiceGroup

It's already heavily reliant on an ini which comes with it to define what each command does, in terms of the Pokémon music engine.

The thing is, even if the Pokemon engine is unusual, most other engines out there have to have the same end effect in terms of what commands do, so it should be entirely possible to modify the code to suit other games.

In other related news, I rewrote the code to support the RB style (direct references) as well as the GSC song table approach. Using this, I was able to get a recognisable Pallet Town out of the ROM, though it's pitched too low (Probably something to do with the different note structure, given that the code's written around note C being in one specific place, which it no longer is). Other than that, it runs reasonably well!

OK, a bit of a development on the Gen 1 music front. It turns out they (Red and Blue, at least) don't use music tables (as in a list of pointers to song headers), and in fact they have collections of song headers grouped together in at least 2, if not 3, sets of locations in the ROM. (Quite how these songs are referenced in game, I don't know, but I digress).

I say 3 as some songs are missing from these headers AND there is a 3rd set of the triangle waves, the other sets of which follow directly on from the headers in question.

Now, the problem is, detecting which style any given games uses will be awkward, and it will be even more awkward if the game uses a different style altogether.

This is, quite frankly, a disheartening discovery (for obvious reasons). I can probably get around it by "creating" a song table in my tool's memory which it could use to navigate the songs, however. This could be complex, especially since I'll have to make it work for an unknown (at compile time) number of "table fragments". I would also need to take into consideration the lack of any obvious boundaries to the table fragments.

However, shy of writing a brand new tool for them, I can't see what else I can do.

Other than this, I have added code to my tool which generates a VG for the ROM you have open, and "rips" the relevant triangle waves along with it. In this way, I can ensure that (if the triangle wave location is known, then they can be ported to gen 3 easily).