Language…
11 users online: 35TCB77, cletus_deletus, Danik2343, Green, Hammerer, howardadam1126, KoJi, Oskise, pnaha, SpacePea, tOaO - Guests: 225 - Bots: 356
Users: 64,795 (2,377 active)
Latest user: mathew

Any kind of optimization tips and tricks someone uses when doing ports with PetiteMM?

I'm mostly reffering to identifying exactly what to optimize when looking at the PetiteMM export, because IMO it's a bit of a mess (not as bad as SPC to MML tho) and is a tad hard to know what notes can be optimized sometimes. Like this port I'm making for example:

https://www.dropbox.com/s/c2j2fffxckvexie/Gauntlet%20IV%20-%20March%20in%20the%20Dark.txt?dl=0

As you can see, it's almost 15KB long, when there's clearly room for optimization, as seen here:

https://dl.dropbox.com/s/uev9tf3lnc5t3z2/March%20in%20the%20Dark.mid?dl=0

Why I haven't been able to manage to know how to optimize it is, like I said before, the PMM export itself, which is kinda messy and hard to read. So yeah, what I wanted to know is like the thread title says: anyone knows of any optimization trick which could work well on this kind of situation? It doesn't seem like Notepad++ is being of much help to finding anything that could be optimized here, so
Layout by Mathos
To deal with this kind of situation, I put the MIDI file into OpenMPT, and then drag notes hundred times to make it have proper note length. Then, I export it to MIDI, and convert to MML.

Now, you got a MIDI that's friendly for porting, and easy to loop.
Originally posted by tcdw
I put the MIDI file into OpenMPT, and then drag notes hundred times to make it have proper note length. Then, I export it to MIDI, and convert to MML.
Essentially, MPT is usually good with note length (within reason of quantization) so it's more about channel rearranging in my case.

I did look at the midi through MPT and it'd be annoying to fix with the pitch bends that create the illusion of notes.
Originally posted by tcdw
To deal with this kind of situation, I put the MIDI file into OpenMPT, and then drag notes hundred times to make it have proper note length. Then, I export it to MIDI, and convert to MML.

Now, you got a MIDI that's friendly for porting, and easy to loop.


Originally posted by Brozilla
Originally posted by tcdw
I put the MIDI file into OpenMPT, and then drag notes hundred times to make it have proper note length. Then, I export it to MIDI, and convert to MML.


Essentially, MPT is usually good with note length (within reason of quantization) so it's more about channel rearranging in my case.

I did look at the midi through MPT and it'd be annoying to fix with the pitch bends that create the illusion of notes.


Well, the problem here's not really the note length being wrong per say (at least for now anyways #smw{-_-;}), but more how it's being a tad hard to recognize what parts to optimize and what parts to not optimize on that mess of a text. Like, you know that there are repeating patterns in quite a few places in the song itself, but when you look in the text, it's a bit too hard to find that same part and optimize accordingly because of the MML's organization.

I mean, I guess I could just try doing it by scratch, but I sometimes think PetiteMM's much better suited for doing ports since you don't have to guess what length is which (except for a few times of course, but even that's much better than just doing the thing by memory IMO), so you know
Layout by Mathos
Originally posted by Ultima
I mean, I guess I could just try doing it by scratch
Not worth it IMO (unless that was your intention to begin with.)#fim{XD}
Still I recommend trying OpenMPT. Unfortunately the square wave channel is all sorts of messed up (pitch bends) and it's likely your mml is the same way right now. I'll check it later.

An alternative is observing the notes on the text while comparing it with software such as anvil studio. I know which part you're talking about that needs to be optimized.
I really should try petiteMM and see how it handles midi to mml conversion of different things. I have a couple questions of my own that I'd like to try and figure out beforehand, so maybe someone who's used it can help me.
First, I've seen a few ports here which have random-sounding lengths, as though the midi wasn't properly quantized. It didn't sound bad, it just sounded like whoever ported it was able to preserve human timing inaccuracies. Does PetiteMM try to be very precise in its mmls, or does it hard quantize to certain values? If I for some reason wanted to make a port that sounded like it was played live on a keyboard instead of quantized, what would be the best way of doing that? I know the MML would be more of a mess, I'm just curious about how it would be done.
Second, does PetiteMM have some way of notating controller events in the MML? I was hoping that I could somehow convert a few of PetiteMM's non-note messages automatically to AMK ones, or at least convert the syntax and then manually adjust the values later. Come to think of it, such a program to transform midi messages to AMK messages might be useful i.e. transform cc1 messages to vibrato commands, pan to the pan command, perhaps portamento to $dd though that would take a ton of work... And I wouldn't worry as much about getting the conversion accurate. If I ran the thing on my own midis, or midi files I'd spent considerable time optimizing, I think fixing the inaccurate commands would be easier for me than trying to read the mml and putting them in manually. I'm faster at writing MML than reading it which is why I've never tried this yet. Probably wishful thinking, but just trying to think of ways to make this as efficient as I can.
Thoughts?
Make more of less, that way you won't make less of more!
Originally posted by Brozilla
Originally posted by Ultima
I mean, I guess I could just try doing it by scratch
Not worth it IMO (unless that was your intention to begin with.)#fim{XD}
Still I recommend trying OpenMPT. Unfortunately the square wave channel is all sorts of messed up (pitch bends) and it's likely your mml is the same way right now. I'll check it later.

An alternative is observing the notes on the text while comparing it with software such as anvil studio. I know which part you're talking about that needs to be optimized.


Wow, you're right actually; OpenMPT is surprisingly a lot better than FL for using it to this purpose; the process might still be a tad slow, but I can definitely be able to do this a lot better now lol

Thanks for telling me about this! #smw{^_^}

Hmm, but about the pitch bend thing on the squares, what would a better way to fix that? Like, does anyone know about the exact notes which are being played there or at least a better way to know exactly which note and note lengths need to be used outside of plain guessing? It definitely wouldn't be as hard if the MIDI didn't bend the notes up like that to simulate actual notes being played when it would've been much easier to just use the actual notes, but yeah, I still need to know lol
Layout by Mathos
Originally posted by musicalman
First, I've seen a few ports here which have random-sounding lengths, as though the midi wasn't properly quantized. It didn't sound bad, it just sounded like whoever ported it was able to preserve human timing inaccuracies. Does PetiteMM try to be very precise in its mmls, or does it hard quantize to certain values?
I believe you can expect precision up to the 64th note, no more than that unless you have the no quantize flag or whatever it is which bloats mml size.

Originally posted by musicalman
If I for some reason wanted to make a port that sounded like it was played live on a keyboard instead of quantized, what would be the best way of doing that? I know the MML would be more of a mess, I'm just curious about how it would be done.
If you need more than 64th I assume you do "petiteMM --no-quantize", I never needed that so have no idea what it generates.

Originally posted by musicalman
Second, does PetiteMM have some way of notating controller events in the MML?
PetiteMM only generates note data, it also ties notes in a way that causes desync. It does b4^b4 instead of b4^4. MasterLink has an easy fix for that in notepad++ that takes less than a minute.
That being said you have to add in channel numbers (separated by semicolon) and everything else manually except tempo which is usually wrong anyway I think.

Originally posted by musicalman
If I ran the thing on my own midis, or midi files I'd spent considerable time optimizing, I think fixing the inaccurate commands would be easier for me than trying to read the mml and putting them in manually.
Most PetiteMM issues arise because the user isn't entirely aware of what is inside the midi. That is why I reprocess them to make sure I don't get unexpected results. The program is far from magic but at the very least it takes care of the most time consuming part, note writing.
The most important things with the midi is that each channel is monophonic (no chords) and there is no more than 8 channels with notedata. The readme doesn't talk about any limitations but with the above I've had very little problems with PetiteMM.

Originally posted by Ultima
Like, does anyone know about the exact notes which are being played there...
I didn't import with enough precision but on channel 6 should be the correct notes. The IT file here I added replaced the pitch bends on CH 6 with notes. 8 and 9 are just echoes so it's not necessary. Note lengths aren't TOTALLY accurate but you get the idea.
Thanks Brozilla for that overview. It's mostly as I expected.
Make more of less, that way you won't make less of more!