Most of our plugins can run in multi mode, this allows up to 16 midi channels with individual presets to be used, saving a lot of CPU instead of creating one instance per midi channel.
Given that we are lv2 plugins and preset selection is done by sending the “plugin state”, this will not work with the current system. Technically, an lv2 preset defines either knob positions for all controls or data chunks for chunk based plugins. In our case, the data chunk is a preset in sysex format, which will load a preset to the currently selected edit buffer, one of 16 slots. However, there is no way to tell a plugin which channel is selected.
Are there any solutions to this or is multi mode just not supported?
We have some multi-timbral engines, but until now, any of them was a LV2 plugin.
We could implement a multi-timbral LV2, but we need a way to load presets for each enabled channel.
Could you add a “selected channel” parameter for this? It would be hidden from the screen, but used to choose the channel we load the next preset.
We should start always from a clean state and then we would load as many presets we want.
The only problem I see is that this “selected channel” would receive all control events too. Or can you export the control parameters repeated for each channel so we can control all of them independently of the selected channel?
In the other hand, creating an instance per channel has been a good approach until now for the rest of LV2 synths. How big is the overhead? Could you create a lighter, single channel instance? Would be missed some interesting features by doing so? I mean, do you have master FXs/LFO that is performed on the mixed output signal? Etc.
This thread just picked up a topic which I was reflecting on myself, during these exciting days of DSP56300 emulators integration in Oram:
multitimbrality of one synth instance from several chains.
AFAIK, it has never been possible to address in this fashion our long-time core synth Zynaddsubfx, that too supports 16 midi channels.
Since in an ARM Raspberry hardware environment the subject of CPU resources economy is by definition sensitive, it would be very interesting if @jofemodo and @riban managed to implement per-processor multitimbrality, although I realise that this kind of workflow somehow conflicts with the current Oram’s chain architecture.
In this way, it would not be out of reach to sustain a snapshot which employs the multi-channel capabilities of a single synthesiser, what that, in the case of computation-intensive plugins like DSP 56300 emulators, would turn out to be crucial, in order to save the significant overhead of starting multiple monotimbral instances.
BTW and a little off-topic: do you think @dsp56300 that, once the adaptation of Osirus and OsTIrus to Zynthian’s presets and parameters handling is complete, there will be any chances to integrate also Vavra, Xenia and the currently developed emu any time soon?
Yes, adding a parameter for the Zynthian build that informs the plugin about the selected channel wouldn’t be a problem.
The controls for individual parameters already exist 16 times, once you attempt to support LV2 parameters expect a big wall of parameters incoming About 3000 for Osirus, about 7000 for OsTIrus. This is actively used in DAWs for automation.
The overhead is huge, it depends on the Synth but in general multi mode saves a lot of processing power because the developers of the DSP code didn’t make any use of “idle” processing. The worst is the Clavia Nord Lead aka Nodal Red 2x, it always processes all voices, no matter if a key is pressed or not.
Feature wise, I’d say that a first version that runs on a single channel only is fine, as it fits the ecosystem much better.
The biggest benefit of multi mode is the TI, as it has FX for every channel separately, you get a true unique synthesis engine 16 times with one instance of the plugin, also, it has six stereo outputs and you can freely route the parts to them.
On Virus A/B/C the FX are global, that will limit you, also it has only three stereo outs. Nord Lead doesn’t have FX at all, but also it has 4 parts only.
The Waldorfs, Vavra has 16 parts, with some FX being per part, some global. Xenia has global FX, 8 parts.
I detect what kind of plugin state is sent, I determine if its an individual preset or the whole plugin state. If a snapshot is technically retrieving the plugin state and later setting it again, it will correctly backup all 16 parts, that is not the issue.
Vavra and Xenia will come, I am not sure about Nodal Red 2X as it has the highest computational overhead. Two DSPs at 120 MHz plus a microcontroller at 25 MHz will definitely hit the Raspi5 hard.
We already implement multitimbral engines for fluidsynth and zynaddsubfx (and I think Linux sampler). For these, each chain uses a different channel of a single instance of the engine. We don’t do this for LV2 yet.
But we could do it. Ideally, it would be nice to have independent audio output for each channel, but we could live with a single one if the volume for each channel is easily accessible in the first page of controllers.
Anyway, i would bet for a lighter single channel implementation and move later to the multi-channel.
