Falcosoft wrote on 2024-08-08, 23:13:

OK, 1. CC#116 marks the start of a loop section. The 3rd byte is the loop count (1-127). 0 means infinite/undefined loop count s […]
Show full quote

Spesek wrote on 2024-08-08, 23:05:

Alright, let's use XMI then. The entire point of this is to standardize loop points, so if you insist on using XMI points, we ca […]
Show full quote

Falcosoft wrote on 2024-08-08, 23:00:

I still do not understand why this kind of standardization could not apply if you choose XMI style loop markers for the standard. The fact that RIFF chunk loop markers have never been impleneted in anything so far does not sound as an advantage for me.
Plesae, help me understand.

Alright, let's use XMI then.
The entire point of this is to standardize loop points, so if you insist on using XMI points, we can use that.

So, how do they work?
Which CC is which loop point? How do you specify multiple loop points?
I honestly know nothing about these except that they use CC messages, so you need to help me here.

OK,
1. CC#116 marks the start of a loop section. The 3rd byte is the loop count (1-127). 0 means infinite/undefined loop count so of course the player/user can use constraints on the loop count.
2. CC#117 marks the end of the loop section. The 3rd byte is not used but should be 127.
3. Multiple loop sections can be defined in the same file but they should not overlap. So you should avoid multiple loop start markers without a loop end marker.

Multiple loops? And which one do we use?
If i understood it right:
let's assume loop 1 loops 3 times
loop 2 loops 5 times
and loop 3 loops infinite times

do we loop though 1 3 times, then play to 2 and loop 5 times and then loop 3 infinitely?
can i do something like
loop 1 start (count infinite)
loop2 start (count 2)
loop 2 end
loop 3 (count 5)
loop 3 end
loop 1 end

Spesek wrote on 2024-08-08, 23:23:

Multiple loops? And which one do we use? If i understood it right: let's assume loop 1 loops 3 times loop 2 loops 5 times and lo […]
Show full quote

Falcosoft wrote on 2024-08-08, 23:13:

OK, 1. CC#116 marks the start of a loop section. The 3rd byte is the loop count (1-127). 0 means infinite/undefined loop count s […]
Show full quote

Spesek wrote on 2024-08-08, 23:05:

Alright, let's use XMI then. The entire point of this is to standardize loop points, so if you insist on using XMI points, we ca […]
Show full quote

Alright, let's use XMI then.
The entire point of this is to standardize loop points, so if you insist on using XMI points, we can use that.

So, how do they work?
Which CC is which loop point? How do you specify multiple loop points?
I honestly know nothing about these except that they use CC messages, so you need to help me here.

OK,
1. CC#116 marks the start of a loop section. The 3rd byte is the loop count (1-127). 0 means infinite/undefined loop count so of course the player/user can use constraints on the loop count.
2. CC#117 marks the end of the loop section. The 3rd byte is not used but should be 127.
3. Multiple loop sections can be defined in the same file but they should not overlap. So you should avoid multiple loop start markers without a loop end marker.

Multiple loops? And which one do we use?
If i understood it right:
let's assume loop 1 loops 3 times
loop 2 loops 5 times
and loop 3 loops infinite times

do we loop though 1 3 times, then play to 2 and loop 5 times and then loop 3 infinitely?
can i do something like
loop 1 start (count infinite)
loop2 start (count 2)
loop 2 end
loop 3 (count 5)
loop 3 end
loop 1 end

In the simplest implementation your last example (nested loops) is not supported since it is also an overlapping one. Otherwise yes, your first example is correct. Of course logic should apply and multiple infinite loops do not make any sense.

I want understand , what for SoundFont do unpack before MIDI play.
If I compress to FLAC any song or wave file and play this file , I can play without uncompress process , because this do on fly , but if I preload any SF2Pack file as SoundFont , BASS MIDI will be first unpack and next play MIDI song.

If possible , do so what not need process unpack compressd SoundFonts , this can give play MIDI with very big SF bank on PC with small RAM size.

Roland User wrote on 2024-08-08, 23:36:

I want understand , what for SoundFont do unpack before MIDI play.
If I compress to FLAC any song or wave file and play this file , I can play without uncompress process , because this do on fly , but if I preload any SF2Pack file as SoundFont , BASS MIDI will be first unpack and next play MIDI song.

If possible , do so what not need process unpack compressd SoundFonts , this can give play MIDI with very big SF bank on PC with small RAM size.

Hi,
Please, ask this from Ian on https://www.un4seen.com at the forum section. We do not know the answer.

Falcosoft wrote on 2024-08-08, 23:31:

Spesek wrote on 2024-08-08, 23:23:

Multiple loops? And which one do we use? If i understood it right: let's assume loop 1 loops 3 times loop 2 loops 5 times and lo […]
Show full quote

Falcosoft wrote on 2024-08-08, 23:13:

OK, 1. CC#116 marks the start of a loop section. The 3rd byte is the loop count (1-127). 0 means infinite/undefined loop count s […]
Show full quote

OK,
1. CC#116 marks the start of a loop section. The 3rd byte is the loop count (1-127). 0 means infinite/undefined loop count so of course the player/user can use constraints on the loop count.
2. CC#117 marks the end of the loop section. The 3rd byte is not used but should be 127.
3. Multiple loop sections can be defined in the same file but they should not overlap. So you should avoid multiple loop start markers without a loop end marker.

Multiple loops? And which one do we use?
If i understood it right:
let's assume loop 1 loops 3 times
loop 2 loops 5 times
and loop 3 loops infinite times

do we loop though 1 3 times, then play to 2 and loop 5 times and then loop 3 infinitely?
can i do something like
loop 1 start (count infinite)
loop2 start (count 2)
loop 2 end
loop 3 (count 5)
loop 3 end
loop 1 end

In the simplest implementation your last example (nested loops) is not supported since it is also an overlapping one. Otherwise yes, your first example is correct. Of course logic should apply and multiple infinite loops do not make any sense.

I wrote this. Is this good?

### Loop points
As there are many implementations of loop points within various MIDI files and none of them are standardized,
this section of the document describes the recommended loop point behavior for the SF2 RMIDI format:

1. Loop points are defined using Controller Change messages within the embeded MIDI data. These loop points apply to the entire file, regardless of the MIDI channel the messages are in.
2. If loop points are present in the file, there must always be an even number of them (two points make one loop). If that's not the case, all loop points must be rejected.
3. Start loop point is defined using CC#116. The controller value specifies the number of loops for this loop point pair. A value of zero is equivalent to infinite.
4. End loop point is defined using CC#117. The controller value is not used, but setting it to value of 127 is recommended.
5. Overlapping (nesting) loops is ILLEGAL. If any nested loops are encountered, all loops within the file must be rejected.
6. If a start loop point does not have a matching loop end point, all loop points in the file must be rejected.
7. If any other non-standard type of loop point is detected within the file while the standardized loop points are present, the software must use the standardized loop points.

All SF2 RMIDI compatible players with loop point capability should support these.
The software can support other, non-standard loop points; it is not required.

Spesek wrote on 2024-08-08, 23:48:

1. Loop points are defined using Controller Change messages within the embeded MIDI data. These loop points apply to the entire […]
Show full quote

1. Loop points are defined using Controller Change messages within the embeded MIDI data. These loop points apply to the entire file, regardless of the MIDI channel the messages are in.
2. If loop points are present in the file, there must always be an even number of them (two points make one loop). If that's not the case, all loop points must be rejected.
3. Start loop point is defined using CC#116. The controller value specifies the number of loops for this loop point pair. A value of zero is equivalent to infinite.
4. End loop point is defined using CC#117. The controller value is not used, but setting it to value of 127 is recommended.
5. Overlapping (nesting) loops is ILLEGAL. If any nested loops are encountered, all loops within the file must be rejected.
6. If a start loop point does not have a matching loop end point, all loop points in the file must be rejected.
7. If any other non-standard type of loop point is detected within the file while the standardized loop points are present, the software must use the standardized loop points.

All SF2 RMIDI compatible players with loop point capability should support these.
The software can support other, non-standard loop points; it is not required.

Perfect!
One thing that we should consider is that maybe only 1 loop start marker could be a valid one, and in this case the loop end implicitly is the end of the song.

@Edit:
Let's forget it. It's not that important and it would unnecessarily complicate the description.
It's not that important

Falcosoft wrote on 2024-08-08, 23:54:

Spesek wrote on 2024-08-08, 23:48:

1. Loop points are defined using Controller Change messages within the embeded MIDI data. These loop points apply to the entire […]
Show full quote

1. Loop points are defined using Controller Change messages within the embeded MIDI data. These loop points apply to the entire file, regardless of the MIDI channel the messages are in.
2. If loop points are present in the file, there must always be an even number of them (two points make one loop). If that's not the case, all loop points must be rejected.
3. Start loop point is defined using CC#116. The controller value specifies the number of loops for this loop point pair. A value of zero is equivalent to infinite.
4. End loop point is defined using CC#117. The controller value is not used, but setting it to value of 127 is recommended.
5. Overlapping (nesting) loops is ILLEGAL. If any nested loops are encountered, all loops within the file must be rejected.
6. If a start loop point does not have a matching loop end point, all loop points in the file must be rejected.
7. If any other non-standard type of loop point is detected within the file while the standardized loop points are present, the software must use the standardized loop points.

All SF2 RMIDI compatible players with loop point capability should support these.
The software can support other, non-standard loop points; it is not required.

Perfect!
One thing that we should consider is that maybe only 1 loop start marker could be a valid one, and in this case the loop end implicitly is the end of the song.

Alright, added that and pushed to github.

PS: I've found This (Made by Ian btw) which seems to do exactly what mod2midi does, except it convert my .XM files perfectly. Maybe if you don't want to maintain mod2midi, you can replace it with this?

Spesek wrote on 2024-08-08, 23:59:

Maybe if you don't want to maintain mod2midi, you can replace it with this?

I know about this, it has not been free for a long time. And I do not think that it supports converting through command line parameters (without using the GUI).

Falcosoft wrote on 2024-08-09, 00:03:

Spesek wrote on 2024-08-08, 23:59:

Maybe if you don't want to maintain mod2midi, you can replace it with this?

I know about this, it has not been free for a long time. And I do not think that it supports converting through command line parameters (without using the GUI).

Maybe suggest a feature request?

Spesek wrote on 2024-08-09, 00:08:

Falcosoft wrote on 2024-08-09, 00:03:

Spesek wrote on 2024-08-08, 23:59:

Maybe if you don't want to maintain mod2midi, you can replace it with this?

I know about this, it has not been free for a long time. And I do not think that it supports converting through command line parameters (without using the GUI).

Maybe suggest a feature request?

I think it has become free since development is stopped. I personally would not bother Ian with this.

Falcosoft wrote on 2024-08-08, 23:54:

Perfect! One thing that we should consider is that maybe only 1 loop start marker could be a valid one, and in this case the loo […]
Show full quote

Spesek wrote on 2024-08-08, 23:48:

1. Loop points are defined using Controller Change messages within the embeded MIDI data. These loop points apply to the entire […]
Show full quote

1. Loop points are defined using Controller Change messages within the embeded MIDI data. These loop points apply to the entire file, regardless of the MIDI channel the messages are in.
2. If loop points are present in the file, there must always be an even number of them (two points make one loop). If that's not the case, all loop points must be rejected.
3. Start loop point is defined using CC#116. The controller value specifies the number of loops for this loop point pair. A value of zero is equivalent to infinite.
4. End loop point is defined using CC#117. The controller value is not used, but setting it to value of 127 is recommended.
5. Overlapping (nesting) loops is ILLEGAL. If any nested loops are encountered, all loops within the file must be rejected.
6. If a start loop point does not have a matching loop end point, all loop points in the file must be rejected.
7. If any other non-standard type of loop point is detected within the file while the standardized loop points are present, the software must use the standardized loop points.

All SF2 RMIDI compatible players with loop point capability should support these.
The software can support other, non-standard loop points; it is not required.

Perfect!
One thing that we should consider is that maybe only 1 loop start marker could be a valid one, and in this case the loop end implicitly is the end of the song.

@Edit:
Let's forget it. It's not that important and it would unnecessarily complicate the description.
It's not that important

I didn't see that edit before. And I agree too, so i've changed it back.

Also, apparently github pages (the free hosting service I'm hosting spessasynth on) has support for markdown parsers. It could translate the markdown in the repo into a proper html page. what do you think?

There are quite a few existing midi looping standards, and every one of them is used by games.

Final Fantasy 7 has loopStart and loopEnd markers, for example. But this standard doesn't support a number of loops. Most games that use it expect infinite looping. whic a player cn schoose to treat as x loops+fadeout.
rpgmaker uses cc111, with 0 and 1 being start and end of loop (or was it the other way around?)
XMI/EMIDI uses cc116/117
Touhou uses cc2/4

And those are just the ones I'm aware of.

There's no real reason for a player not to understand all of them, though a creator should probably use XMI, since it seems to be a more capable loop format compared to most of the others.

A loopstart without a loopend is unlikely to actually loop right, and it would be very difficult to try and correct for that, thoug hit makes sense as a fallback.

Note that notes CAN extend past the loop point, and you need to be sure that the not of get sent at the right ime even when it's past the loop point. That's part of wht makes midi looping awesome compared to wav/mp3/ogg looping.

Hi Falco,

It seems like "Override maximum loop count" does not work as intended, if at all, with my example .xmi file (attached here).

Tried both with latest stable 6.4 version and development 6.5 one.

If "Override..." is unchecked, and "Repeat One" button is pressed, then everything's fine.
If "Override..." is checked, then "Repeat One" state doesn't matter, no part is being looped. Maximum loop count makes no difference here as well.

Attached is "Introduction.xmi" from Ultima Underworld (should be played with MUNT).

Or perhaps I'm missing some not-so-obvious setting?

Regards.

[EDIT]
Happened to find a looping .MIDI (g_castle.mid from Shadowcaster game), seems to work fine. So I guess the issue only happens with .XMI

nmonte wrote on 2024-08-22, 23:59:

Hi Falco, […]
Show full quote

Hi Falco,

It seems like "Override maximum loop count" does not work as intended, if at all, with my example .xmi file (attached here).

Tried both with latest stable 6.4 version and development 6.5 one.

If "Override..." is unchecked, and "Repeat One" button is pressed, then everything's fine.
If "Override..." is checked, then "Repeat One" state doesn't matter, no part is being looped. Maximum loop count makes no difference here as well.

Attached is "Introduction.xmi" from Ultima Underworld (should be played with MUNT).

Or perhaps I'm missing some not-so-obvious setting?

Regards.

[EDIT]
Happened to find a looping .MIDI (g_castle.mid from Shadowcaster game), seems to work fine. So I guess the issue only happens with .XMI

Hi,
The problem is not XMI specific. This file would not work properly even if it was a MID file. This file has 9 loop start markers and only 1 loop end marker. This way the behavior is undefined. According to the player's loop counter logic it decreases the counter 9 times when it encounters the 9 loop start markers one after the other. When no maximum loop count override is applied there is no problem since there is no loop counter.
To mitigate this problem you can set the maximum loop count override to 10 instead of 1 to make it loop once (because of the above described logic). Or here is a fixed version of the file:

Falcosoft wrote on 2024-08-23, 07:39:

Hi, The problem is not XMI specific. This file would not work properly even if it was a MID file. This file has 9 loop start mar […]
Show full quote

nmonte wrote on 2024-08-22, 23:59:

Hi Falco, […]
Show full quote

Hi Falco,

It seems like "Override maximum loop count" does not work as intended, if at all, with my example .xmi file (attached here).

Tried both with latest stable 6.4 version and development 6.5 one.

If "Override..." is unchecked, and "Repeat One" button is pressed, then everything's fine.
If "Override..." is checked, then "Repeat One" state doesn't matter, no part is being looped. Maximum loop count makes no difference here as well.

Attached is "Introduction.xmi" from Ultima Underworld (should be played with MUNT).

Or perhaps I'm missing some not-so-obvious setting?

Regards.

[EDIT]
Happened to find a looping .MIDI (g_castle.mid from Shadowcaster game), seems to work fine. So I guess the issue only happens with .XMI

Hi,
The problem is not XMI specific. This file would not work properly even if it was a MID file. This file has 9 loop start markers and only 1 loop end marker. This way the behavior is undefined. According to the player's loop counter logic it decreases the counter 9 times when it encounters the 9 loop start markers one after the other. When no maximum loop count override is applied there is no problem since there is no loop counter.
To mitigate this problem you can set the maximum loop count override to 10 instead of 1 to make it loop once (because of the above described logic). Or here is a fixed version of the file:

The attachment 101 - Introduction_fixed.zip is no longer available

Oh, thank you so much for the fixed file! I would've never even thought of setting the value to anything greater than 6, while trying to figure out this behavior.

Because here discussion about XMI files , I too to ask ) have game Mortal Kombat II , and in this game have MIDI files a strange format , this XMI or other ? If this XMI , as play and convert this files to standard MIDI format ?

Roland User wrote on 2024-09-28, 08:43:

Because here discussion about XMI files , I too to ask ) have game Mortal Kombat II , and in this game have MIDI files a strange format , this XMI or other ? If this XMI , as play and convert this files to standard MIDI format ?

Hi,
None of the files in this package are valid SMF (.mid) or XMI files.
They seem completely header-less for me so most likely they contain only the raw data required by the engine.

Hi, I have a question.

The attached MIDI file (Y4002_02) shows up in FSMP6 as 32-channel MIDI, but I can't find any MidiPort meta messages in it.

Running it through VBSYX, nothing related to ports shows either. It's just a mode set, drum part and then effects.
While the first one is "SC88 Mode Set" message, other attached MIDI (_th07_19) uses that exact message and yet shows up as a regular, 16 channel MIDI.

Am I missing something? How does MP differentiate between the two? Does it just check if SC88 mode MIDI has more than 16 tracks and assumes 32 channels?

Spesek wrote on 2024-09-28, 11:39:

Hi, I have a question. […]
Show full quote

Hi, I have a question.

The attached MIDI file (Y4002_02) shows up in FSMP6 as 32-channel MIDI, but I can't find any MidiPort meta messages in it.

Running it through VBSYX, nothing related to ports shows either. It's just a mode set, drum part and then effects.
While the first one is "SC88 Mode Set" message, other attached MIDI (_th07_19) uses that exact message and yet shows up as a regular, 16 channel MIDI.

Am I missing something? How does MP differentiate between the two? Does it just check if SC88 mode MIDI has more than 16 tracks and assumes 32 channels?

Hi,
1. Unfortunately the 'multi-port SMF file' situation is much more complicated than it should be. In case of your example Y4002_02.mid file the track name meta event indicates what port should be used. Namely you can find track names with 'PartA' and 'PartB' prefixes.
What is more even in official Midi specification you can find the 0x9 device (port) name meta event that officially made the 0x21 port number meta event 'obsolete'.
And there are other 'creative' methods how authors made out of standard markers for assigned ports.
You can also find Midi files in the wild with 0x21 port number meta events that do not make any sense. E.g. port 0, 1, 127 are assigned to 3 tracks and the number of used tracks/channels are only 5.

2. Midi Player uses heuristics to identify real multi-port Midi files and also uses heuristics to identify false multi-port Midi files. But 'more than 16 tracks' is not a marker for Midi player to identify real multi-port Midi files.

Hi,
Thanks for your response, Zoltan.

1. Yeah, I agree. And some files don't mark, well, anything at all. I have to manually set up 0x21 messages for it to work properly which can be a pain.. Fortunately MIDI 2.0 solves this issue, except it's almost non-existent right now and useless for retro tracks... MIDI 1.0 should've just used a separate byte for status and a second one for the channel IMO, it would've made things a lot simpler.

2. I see... May I ask for some sort of pseudo-code on the logic FSMP6 uses for determining these? I'd like to implement this functionality into my synth if you don't mind...