I am currently, and have been for months on and off, working on an AMK volume preprocessor which does volume scaling, pan conversion, and later ADSR, possibly bends.
I initially used percent-based commands, which I discovered to be too verbose for volume and pan switching, which is done frequently.
I then switched to directly parsing for "v" and "y" characters, which crashes upon encountering them in #samples and #instruments sections. (I pass-through comments) (Excluding quotes will break volume-scaled macros)
Any advice? The output, as currently planned, must be AMK-readable and is currently designed to be human-readable and formatted similar to its original appearance.
(Maybe exclude curly braces?)
Could you be more clear on what you're trying to achieve with this?
Converts MIDI volumes to AMK volumes automatically.
Later will make human-readable ADSR and other commands. Specifically the ones which are extremely ugly or difficult to use.
Originally, I was going to make a system where you can create blocks of music, which can be inserted wherever you want in the final product. I don't think it worked out very well, and was rather awkward to use, at least for me. Maybe a GUI part arranger would work better.
I ended up not parsing anything within curly braces.
My system as-is will crash and burn with lowercase macros containing reserved characters.
It's better when you don't have to open the readme file every time you want to recalculate it, and make mistakes copy-pasting, and have to deal with a weird GUI, and make it difficult to read what you already posted. It's a significant inconvenience. Though it is useful for getting the right setting, not so much being convenient or easy-to-edit.
While it may sound useful, converting midi volume to SMW probably won't work; the volume of the midi samples aren't the same as those of SMW or any SNES game, so if you use the exact same values from the midi, it may not sound as good as it did originally, unless you rip all the original samples and use them directly, but I doubt anyone would do that. Also, some people (like me) make midis with Yamaha XG, which has different volume for its samples, so if it sounds good in XG it might not sound good on GM or in SMW.
In my case, I'm porting a DS song with more-or-less original samples.
I just discovered the DS SSEQ engine is quadratic = (vol*vel)^2. loveemu stated that the SNES channel volumes are quadratic, and as I'm ignoring the qxx command, I can just straight-out multiply DS (vol*vel) by 2 (or any constant), slot it into the SNES volume field, and it will sound correct, if I use the same samples as the original song.
The General MIDI [EDIT]developer guidelines[/EDIT] claims volumes are quartic (n^4) and velocities must match Roland Sound Canvas (no formula provided). In practice, BASSMIDI synth has exponential (around 10^(volume/100) absolute = volume/10 dB) volumes and quadratic velocities. A rat's nest trying to figure out the curves.
In short, my strategy will work. My MMK tool is codeveloped with my Port-a-Potty viewer, which currently just multiplies (vol*vel). That is sufficient for DS, but not for MIDI.
If I intend Port-a-Potty to be a general-use tool, I need to properly convert MIDI (vol, vel) pairs into a single number. Additionally, I need to add a volume multiplier in my MMK parser to compensate for sample volume differences, and possibly more new volume curves, if it proves too difficult for my Viewer to convert MIDI volumes to quadratic.
Of course, there is a MIDI standard, there is my BASSMIDI observations, and maybe XG, if it differs from BASSMIDI.
What are the XG volume and velocity curves?
But that's assuming everyone will rip the samples from DS games, and not many people know how to do it, not to mention that some samples are incredibly big to be converted to .brr; it's nothing that can't be fixed by editing the sample, but then you'll have to know exactly what you're doing or the result won't be as good as it could be. Also, most people ports with samples from other SNES games, or even use the original SMW ones, so that may be a problem.
As for XG's volume and velocity curves... I honestly don't know; XG is kinda mysterious and there isn't much information about it (at least in English) since Yamaha doesn't support it anymore, so its official page has been deleted. There are also many versions of XG out there, so it's kinda hard to tell. The one I use is S-YXG50 and sometimes S-YXG2006LE, if that helps.
That said, I think I could use your (future) tool, especially if the GBA format is also quadratic, since I find very fun to port GBA songs with their samples.
It's not too difficult to add a customizable scale factor, assuming quadratic. (Who doesn't love fudge factors?)
I assume because the empirical MIDI velocity is quadratic, most MIDIs are made with quadratic in mind. Do most MIDIs use expression or channel volume for volume bends, which one? (SSEQ rips use channel volume, so I only support them so far). If converting from a hand-sequenced MIDI, the fudge factor can be used to compensate for the different channel-volume curves.
It wouldn't be difficult to add more curves to select between.
Anyway, my current volume scaling is "multiply by 255/127", which is much simpler than I expected, and honestly a lot of trouble to develop an entire preprocessor for, though likely useful for others wanting to fine-tune the relative channel volumes. However, my MIDI viewer was absolutely worth the time programming, given how much it helped my port.
Regarding more useful features, I added syntactical sugar for pitch bends, etc., allowing you to specify durations in terms of either decimals or fractions of a beat (qtr-note). Will add whatever is convenient for my port.
I think I have (untested) segment rearranging (removed volume continuation because it was awkward to use)
Which tool are you talking about? MIDI viewer or AMK preprocessor?