Posted
Hi. From this topic, https://users.cognitone.com/comment/26689, I quote information about dynamic sound allocation:
The dynamic allocation paradigm relies on the fact that a specific sound is sufficiently addressed by a program number. That's not the case with multiple Sprike instances of which some have customized sounds. If you have multiple Sprike instances they may not share the same internal patch data. Thus selecting e.g. program 23 on any instance may play a different sound.
The purpose of dynamic allocation is to share the same synth depending on which arrangement or library phrase is currently in the foreground. If you have a library with phrases for 25 different Sprike sounds, the library rack only needs a single Sprike instance. Same if Sprike instances are provided by the global rack.
We could save the entire plugin state with each phrase. But that would dramatically slow down browsing a library and blow them up to hundreds of megabytes. Same for the global rack. So this dynamic sharing of resources makes sense.
I think the first step should be to save the entire loaded bank with a Sprike instance. So if an instance contains more than one customized sound, these will be saved and restored too.
A second step may be to always disable dynamic allocation for arrangement-owned sounds. These sounds are never shared and could as well all be fixed. That will emulate the behavior of a DAW.
This is a Synfire topic I have never understood well, and really still don't, but I'm a bit closer to understanding it after reading the above.
I have tried searching the latest edition of the online manual.
'dynamic allocation' returns 30 documents, none of which is immediately obvious as explaining the topic.
'dynamic sound allocation' returns 111 documents. Again, none of which are immediately obvious as explaining the topic.
In both cases, it's way too much to wade thru all of it in hope of finding a good full explanation.
So, my questions are:
- Does there exist a Forum post, Blog entry, part of the Help, or some other document that explains Synfire's dynamic sound allocation in detail, from the beginning, in simple and direct terms for a naive reader? (If so, where?)
- If the answer to #1 is "No", could such a document be created?
Thanks.
Di., 13.05.2025 - 18:10 Permalink
Dynamic sound allocation is a technical term that users should not be bothered with. It is not explained in the manual. There are some pages that hint at it though.
https://docs.cognitone.com/synfire/EN/concepts/MidiRouting.html
https://docs.cognitone.com/synfire/EN/interface/PartDevicesVariants.html
There's not much to explain. Unlike a DAW, Synfire can open multiple arrangements and libraries at the same time, which may share the same devices on the global rack.
If Song A uses 12 sounds on "Soundcase" and Song B uses 10 different sounds on "Soundcase", they can still both be open and play although there are only 16 channels available. The song that comes to the foreground claims and selects the sounds it wants, replacing any sounds that the previously active song may have claimed and vice versa.
Similarly, within a single arrangement if an instrument needs a new sound on "Soundcase" (or any other multi-timbral instrument) it looks for the next unused channel and claims it. If an instrument is removed, its channel is available again. You don't have to micro-manage that.
Di., 13.05.2025 - 18:20 Permalink
These days most users are used to loading a plug-in and then setting it up entirely in itself, i.e. using the sound browser provided by the plug-in developer. Many plug-ins can't even select programs via MIDI message anymore.
But since Synfire needs meta data for each sound (category, playing ranges, CCs, etc) this is not sufficient. Therefore users need to set this information in Synfire's sound wizard manually. Initially I had doubts but that seems to be intuitive enough. Since the introduction of the wizard we rarely receive support requests regarding sound selection anymore.
If this dynamic "swapping" of sounds is confusing we might ditch it. Or disable it by default. Users would then be required to pick an unused MIDI channel for every sound and keep track of which channels are used.
Mi., 14.05.2025 - 17:09 Permalink
Thanks for the additional comments / information, and for the documentation update!
This gets to the core of it, I think:
If Song A uses 12 sounds on "Soundcase" and Song B uses 10 different sounds on "Soundcase", they can still both be open and play although there are only 16 channels available. The song that comes to the foreground claims and selects the sounds it wants, replacing any sounds that the previously active song may have claimed and vice versa.
I appreciate that specific scenario description.
As for:
If this dynamic "swapping" of sounds is confusing we might ditch it. Or disable it by default. Users would then be required to pick an unused MIDI channel for every sound and keep track of which channels are used.
I see no reason to undo what's working! (Please don't)
Having the extra explanation / documentation was exactly what was needed, IMO.
Thanks again.