General MID (GM) considerations

[jlearman]

sfizz might be ideal for certain GM applications.

In case you're not familiar, the idea with General MIDI is a set of program assignments (e.g., piano is prog 1, etc.) so that people can create fully-orchestrated MIDI compositions in a wide variety of genres and share them. For most of us, when we click a MIDI file link on the web (or when a web page has a background MIDI file), the music plays using a standard default GM MIDI player for our OS. On Windows, it's quite horrible, as it's software that's pretty much based on 1980's sounds and 1990's hardware, with serious memory limitations.

It seems to me that anyone needing a GM music player, possibly embedded in a game or other product, could really benefit by using sfizz and any of several royalty-free GM sfz's that are in the process of being created.

To support GM, the player would need to support MIDI channels (lochan/hichan) as well as programs (loprog/hiprog), though only when hiprog=loprog and hichan=lochan. I think it might need another hack to support the fact that for the drum channel the patch numbers map to different patches than for the melodic instrument channels. That's for GM1; there may be other considerations for later versions. GM2 requires bank support, for example.

I'm raising this issue for discussion purposes. Personally I don't use GM; I was just tangentially involved. It might be helpful to figure out what is actually required, and also whether there's really a "market" for it.

@kinwie may have more to say on this as he has more experience with GM.

[paulfd]

Thanks for raising this issue. I discussed a bit my stance on the matter in https://github.com/sfztools/sfizz/issues/1047#issuecomment-983013950. To make it short, last I considered it, supporting 16 channels in the engine itself was taxing on resources and data structure sizes. It's also slightly weird on some front, for example polyphony. If you reach the engine limit, should the newly started crash cymbal steal a piano voice or a bass voice?

The answer probably is "a voice on the same channel", which leads me to my take on the matter. All applications I can think of with multi-channel can work with multiple sfizz instances (programmatically). It's even true for program numbers on some level, although after our recent discussions hiprog and loprog probably have very little impact in the code complexity and data structure size. Multiple sfizz instances means it's conceptually simpler both for me and for library designers, and you need not worry about including multiple files, overlapping group numbers, having overriding global headers and stuff like this. The performance should be largely the same. I'm happy to discuss other applications which I did not consider though.

A game or another product shipping sfizz as a dependency can readily create as many sfizz instances as they like and handle their event dispatching, it's a very simple task. What is definitely lacking is something like the ARIA engine for sfizz, which would present you with 16 empty sfizz instances, one per channel, and handle the MIDI dispatching. Having it runnable standalone would probably also be nice. As far as I can tell there are no show-stoppers at all, it's just that no-one stepped up to do so until now. It's mostly GUI programming and implementing the necessary bindings for the chosen audio API target.

It's not in my immediate todo list so I'm tagging it as a good first issue. If someone wants to take it on, I'll gladly help.

[jlearman]

Sounds reasonable to me. The biggest disadvantage to this approach is that the (very large) GM sfz would need to be read 16 times, once for each plugin, which would slow down loading of the game or whatever. But I think it's reasonable to stick with this approach and deal with that issue only if anyone ever actually cares.

[kinwie]

Hey Jeff!

This issue title is too big and long to be discussed in full details. I chime in sfizz issue tracker here as much as I can to share some useful toughts to Paulfd and the team for things that I undestand. I have to say that I migrate to other sample format...hmm... But okay, let's talk about this in brief.

To comply to full General MIDI specification nowaday is a big question, is it needed? Afaik, now that is a big hole that most modern developers and manufacturers ignores. As we know, its official standard specs has a lot of stuff in it, things like SysEx, RPN, etc. They was made so there is a standard for different MIDI devices to communicate correctly. That was useful 20 to 30 years ago.

Nowadays, MIDI products evolved with more advanded features. Sample and sound libraries use modern and intelligent programming. MIDI hardwares goes generic with flexible users programming option rather than sticks to a fixed GM function (e.g. Cutoff doesn't has to be CC 74,, etc). GigaSampler pioneered KeySwitch which is now "quite a standard" because it's very useful, but it's not a MIDI compliant. And now MPE and MIDI 2.0 already starts to spread, so this thing is moving forward very fast, imo.

Though as I recall, some default parameters in sfizz are GM, e.g the Expression CC 11 which added by @jpcima. What I can see, what left in SFZ version 1 opcodes list that not yet implemented in sfizz is the lochan / hichan, and SFZ version 2's loprog / hiprog` which they are the GM related opcodes. So, let's just narrow down this issue title to just talk about lo/hiprog and lo/hichan in SFZ and atm, forget those RPN, Sysex stuff.

For those two opcodes, chan and prog :

• lo/hichan works in rgc sfz.dll and Cakewalk players (DropZone, Rapture, DimPro)
• lo/hichan just parsed, but not working in sforzando
• lo/hiprog doesn't work in Cakewalk players. It works in sforzando

Like Paulfd said, I agree that lo/hichan is actually not ideal for a Single-slot player like sfizz and sforzando. It's a multi-timbral thing. I think it's rarely used in nowadays sample libs. Though, afaik one kind of intrument use it a lot. The MIDI Guitar controller, where each string is assigned to each channel, so e.g. each string bend can be indiependent.

I know your intention is to get a GM sound library to works correctly with sfizz. I have no objection nor suggestion if lo/hichan and lo/hiprog need to be implemented or not. It's all depend to sfizz developer to decide. I'll just share some cases and things that I've encountered within sfz usage.

[atsushieno]

Performance wise, I have been building a complete set of orchestra track which consists of 31 midi tracks like this, entirely with sfizz + Virtual Playing Orchestra 3 (with a few exceptions):

It is a dogfooding PoC for my music macro to MIDI2 to Tracktion Engine tool and thus directly loadable on Tracktion Waveform (like the sshot shows). This track of the entire 31 midi tracks is loaded only 3-5 sec. and can play without freezing tracks, on my Core i7 laptop. Maybe there are rooms for improvements like Kontakt does for multiple plugin instances, but it's definitely workable on the DAW.

[paulfd]

I have to say that I migrate to other sample format...hmm...

Re-reading this, @kinwie what did you move to if it's not too personal?

[kinwie]

Re-reading this, @kinwie what did you move to if it's not too personal?

The last option for me, kontakt :)

[paulfd]

The last option for me, kontakt :)

😱 Hopefully we get good enough that you come back to us at some point!