Replies: 7 comments
-
|
Thanks for raising this issue. I discussed a bit my stance on the matter in #1047 (comment). 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 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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Hey Jeff! This issue title is too big and long to be discussed in full details. To comply to full General MIDI specification nowaday is a big question, is it needed? 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. For those two opcodes,
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 know your intention is to get a GM sound library to works correctly with sfizz. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
Re-reading this, @kinwie what did you move to if it's not too personal? |
Beta Was this translation helpful? Give feedback.
-
The last option for me, kontakt :) |
Beta Was this translation helpful? Give feedback.
-
😱 Hopefully we get good enough that you come back to us at some point! |
Beta Was this translation helpful? Give feedback.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions