Falcosoft wrote on 2024-08-08, 22:16:I think you missed this: […]
Show full quote
Spesek wrote on 2024-08-08, 22:12:Hi Zoltan,
1. Oh well...
To specify more clearly, this was my idea:
This chunk would allow loop points to be standardized: […]
Show full quote
Falcosoft wrote on 2024-08-08, 21:46:Hi,
1. This is an idea I stronly disagree with :(
I think there is already too many kinds of loop markers and one more cannot he […]
Show full quote
Hi,
1. This is an idea I stronly disagree with 🙁
I think there is already too many kinds of loop markers and one more cannot help in this chaotic situation.
Not to mention the problem of what should happen if some kind of loop points already exist in the Midi file that the rmi author does not recognize (but the affected player does) and they are not consistent with the loop points that are defined in the rmi chunk.
Furthermore testing and correcting loop points is much harder in the rmi chunk than in the Midi file itself so from a pure practical point of view I do not think that this would be helpful for authors either.
So I beg you not to include this in the specification...
2. I have already talked about this many times before so let me link an earlier answer:
Re: Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
Hi Zoltan,
1. Oh well...
To specify more clearly, this was my idea:
This chunk would allow loop points to be standardized:
- This means that all RMIDI-capable players would use them. That way no matter what the actual MIDI file uses, if the RMIDI writing software recognizes the loop points, it would write them in an official, specified way so all software (even that ignoring cc or marker loops) playing back the file would be aware of them.
- RMIDIs without LPTS chunk (as it's optional) would behave like normal MIDIs (capable software can try to find the loop points)
- To turn off the loop, the LPTS chunk would have both loop start and loop end set to 0, indicating no loop. This also disables loop points within the MIDI file itself.
- And the loop points would override the loop points in the midi. That way both loop aware and non-loop aware software would loop using the LPTS chunk.
That was my general idea. And I would add all these constraints to the spec, ensuring the same behavior everywhere.
If you're still against it though, I won't add it. You're the standard's creator, after all.
2. That's fair. Curious if BASS being closed source was Ian's choice or being forced to stay closed due to legal reasons like you.
I think you missed this:
If your intention is really some kind of standardization then I think you should pick an existing one like CC#116/CC#117 since they are more versatile (they can define the loop count and are not restricted to 1 start and 1 end) and they are already supported in 2 kinds of indepentend Midi 'standard' (i.e. EMIDI and XMI). So you can mention in the specification that this kind of loop markers are recommended in the Midi file itself.
Furthermore XMI/EMIDI style loop markers are already supported in most Midi players that are aware of loops (e.g. XMPlay, Foobar's Midi plugin, and other players that can play .xmi files).
Hi,
Yeah, I think you edited your post while i was writing mine.
Generally, I think we want to avoid adding stuff to the MIDI file. And even if it's "standardized" the only way I found out about cc's being used as loop points, was when I played a MIDI with these through FSMP6. Fluidsynth (the biggest (I think), most well known SF2-based midi player (and used in VLC) does not use these. And it probably won't since it isn't in any specification. (When I suggested adding support for the 0x21 meta message for multi-port, it was promptly rejected.
Using the LPTS chunk will be officially standardized.
And about multiple loop points: sure thing! I'm not sure how do multiple loop points work, so you will have to help me describe the behavior
For the chunk itself, it would be pretty straightforward:
LPTS:
1 byte of looping mode (o would be forward, 1 would be backwards, 2 would be back-and-forth. More can be added later if you have ideas)
any amount of LPNT chunks (minimum of 2, being start and end), where:
LPNT:
tt tt pp pp pp pp
where tt is the loop point type (0 is start, 1 is end, More can be added later. Also it's 2 bytes because the chunk's length has to be even anyways so why waste it on a zero byte)
and pp is the 32-bit little-endian tick number for a given loop point.
If loops should be disabled, the LPTS would have a length of 1 with a single byte of 0, indicating no loops. If LPTS doesn't exist, normal MIDI loop behavior is enabled.
If this solution lacks any features that the cc loops offer, let me know so we can add them. Only when we're really sure about loop points having enough flexibility, I will add the final LPTS version to the spec.
What do you think? Are you still against the idea?
