Multiple Sequences (mptm): Rearrange

[Skaven]

I'm running pretty close to the 255 Order limit in my game music project, and it would help if I could sort the unused / test / sketch patterns I want to keep to the last sequence.

Would it be technically feasible to make the multiple sequences re-arrangeable? Right Click: "Move Up" / "Move Down", drag & drop or such?

What is the maximum number of Patterns an .it or a .mptm can contain? I can of course simply remove the unused / test / idea patterns from the Sequence and just find them in the Patterns list, but the Sequence is a handy way to keep them available and visible.

[Saga Musix]

I guess reordering sequences would be doable. For now, it's possible to select a range of order items and use the cut&paste functionality (it just copies the order numbers, so it does about the same thing).

What is the maximum number of Patterns an .it or a .mptm can contain?

240 patterns for IT, 4000 for MPTM.

[Skaven]

4000? Wow.  Too bad game tunes still need to be converted to .IT so we can't use that many patterns in games. Unless BASS.DLL and/or FMOD start supporting .mptm format directly. It's not radically different from the other tracker formats, is it?

Oh yeah, and since the Order list is still clamped at 255 (otherwise the Bxx command couldn't work), there wouldn't be a way to include all those 4000 patterns into a sequence....

[Skaven]

Yeah, except... if .mptm is supported directly, then each separate sequence can contain 255 orders and patterns, and then you could indeed make use of 4000 patterns  (how many sequences can there be?).

Then seeking different sub-tunes could be done by seeking Sequences instead of Offsets within the sequence. That would be very convenient indeed, since there would be no need to convert the .mptm back to .it.

Hmmmm. Interesting indeed.

But this would have to be implemented by the authors of BASS.DLL and FMOD.

[Relabsoluness]

It's not radically different from the other tracker formats, is it?

Currently mptm is extended(hacked) IT-file.

Oh yeah, and since the Order list is still clamped at 255 (otherwise the Bxx command couldn't work), there wouldn't be a way to include all those 4000 patterns into a sequence....

Sequences can also be 4000 items long, but there indeed are limitations like the one you mentioned.

(how many sequences can there be?).

Currently 50.

[Skaven]

I sent an email to Ian Luck (author of BASS.DLL) if .mptm could be supported directly. Let's see if it would be feasible.

[Skaven]

Ian looked at the .mptm format and understood it's basically .IT with extended metadata. He said it should be possible to seek from .mptm with sequence numbers, then offset, but added that since the .mptm format still gets changed, he'd prefer to do it later.

Works for me.

[Saga Musix]

Yeah, things might still change, so it's probably a bit too early for doing an "official" release with MPTM support (though ultimately it would nice to have that, of course)

[LPChip]

How hard would it be to make an in_mptm for say, winamp and xmplay?

I'm sure if we can create a plugin for that, Ian can use the code for that part to generate what he needs for bass etc. Perhaps even as an interface to a plugin we develop?

[Saga Musix]

This "in_mptm" you are talking about does already exist and is called libmodplug (it just lacks the MPTM loading functionality, but then again, it shouldn't be difficult to create an updated version of libmodplug from the OpenMPT core). Why write a plugin if XMPlay/BASS already has all the functionality apart from reading the extended fields like multiple sequences? This just doesn't make sense at all.

[LPChip]

This "in_mptm" you are talking about does already exist and is called libmodplug (it just lacks the MPTM loading functionality, but then again, it shouldn't be difficult to create an updated version of libmodplug from the OpenMPT core). Why write a plugin if XMPlay/BASS already has all the functionality apart from reading the extended fields like multiple sequences? This just doesn't make sense at all.

I was thinking about this because we're the ones who continue to build on the mptm format, not un4seen. If they want to wait with adding support for our mptm format because its subject to change, we can take a midway.

Just my 2 cents.

[Relabsoluness]

This "in_mptm" you are talking about does already exist and is called libmodplug (it just lacks the MPTM loading functionality, but then again, it shouldn't be difficult to create an updated version of libmodplug from the OpenMPT core). Why write a plugin if XMPlay/BASS already has all the functionality apart from reading the extended fields like multiple sequences? This just doesn't make sense at all.

I think it's misleading to say that libmodplug "just lacks" the MPTM loading functionality: as far as I know it lacks more or less every extension and playback fix introduced by OpenMPT and there are plenty of those(accumulated since 2004). Many of them may require significant changes in the source and simply updating libmodplug sounds like an arduous task.

[Skaven]

Also, how does BASS.DLL's .mo3 format sit in the picture, if libmodplug (or its future equivalent) is used?

[Saga Musix]

Also, how does BASS.DLL's .mo3 format sit in the picture, if libmodplug (or its future equivalent) is used?

libmodplug does not natively support mo3; unmo3.exe would have to be used. If someone does a "new" libmodplug based on the OpenMPT code, it would support mo3 through the unmo3.dll specially created for OpenMPT; in both cases, the license of the mo3 package would apply.

[Saga Musix]

Better late than never, but I finally implemented sequence rearranging and some related improvements (e.g. duplicated sequences are now added next to the duplicated sequence rather than at the end). These improvements will make it into OpenMPT 1.29.