Hi @ll,
I am currently trying oram. What was missing for me was the possibility to use a kind of mix-bus or a send.
More exactly: Can I create an audio-chain with a reverb in it and send (with a kind of send pot from other chains into this reverb chain?
I am not sure if I havn’t found a way o doing this or if this is currently impossible…
Yes… and no!
You can now use the chain option menu’s “Audio Out” option to route the chain’s audio to any physical audio output, any other audio chain’s input (including main mixbux) and any processor’s sidechain input. So you can add a chain that acts as a group with its own effects chain and route other chains through it. (I find it useful to rename the chain, e.g. “Group 1” to keep track of where I am routing.)
What is missing from this is a send level control. A chain’s fader effects how much signal goes to any other chain. I can see that a “Send level” control would be advantageous but…
For every send level there needs to be a control. The quantity of which would be dynamic and a bit of a UI design challenge. There needs to be a calculation for each send which adds to the complexity and CPU load of the mixer. If we had a fixed number of sends then we would have that quantity chain outputs wit associated CPU load and routing complexity.
As I write this I can see it may not be insurmountable. We could have some controls in each chain for send and add extra “Audio Out” menu options for each send. We could not process any output that is not routed. (We do this optimisation already for channel inputs and outputs.)
I am aware that our wonderful @jofemodo will be pulling a concerned frown at the thought of extending the audio mixer further (don’t ask him about phase reverse!!!) and we would probably need to limit the quantity of sends to a fixed number, e.g. 2. We would also need to consider if we had pre/post fader sends.
This is worthy of a feature request.
Thanks Brian!
Yes, I see that the setup is very complex. Especially when you have stereo handling. I know how complex simple sounding setups are, because I have this kind of problem in MicroDexed… 4 sound generators, one global reverb and three chorus and delay instances. Also mono-to-stereo panning and NO phase control…
But I think this is worthy to implement (not now). Currently my Zynthian sound setup is limited. The handling of reverb for more than one engine without sends is not really good.
Perhaps an easy way may be to use the mono/stereo volume pods and splitter from MOD-UI as LV2 plugin an add them to the FX? Hmmmm… I will try this…
Volume level calculations are not really CPU hungry but the copying of buffers in the chain will add some CPU cycles. The big problem will occur when one engine is running on one CPU and the global reverb on the other…
I will try to open a feature request soon.
Regards, Holger
There could be a plugin (I don’t know if it yet exists) that exposes side-chain inputs and allows those to be level controlled, i.e. acting as a mini mixer. You could then route chains to the side-chain inputs of the group chain and adjust each’s levels. It would put the send control in the group chain rather than the (possibly more intutive) source chain but it would provide the required fuctionality. What do people thing? If this was thought to be acceptable we could create a side-chain mixer plugin… relatively simply - maybe!
Actually the simple mixers (like AMS Mixer) are better but even those are overly complex. We don’t really need to mute, solo, pan, etc. and we want stereo inputs. LS Mixer offers stereo inputs but is also too complex.
I have added sidechain config uration for may of these mixers so they may be used for this purpose (or other purposes, e.g. setting up monitoring feeds, etc.) but I still think we would benefit from a much simpler, multichannel gain control plugin, similar to the Gain 2x2 but a Gain 8x2 for example. You can update Oram to use these.
The question remains though - is this an acceptable / preferred / optimal workflow?
I have added sidechain config uration for may of these mixers so they may be used for this purpose (or other purposes, e.g. setting up monitoring feeds, etc.) but I still think we would benefit from a much simpler, multichannel gain control plugin, similar to the Gain 2x2 but a Gain 8x2 for example. You can update Oram to use these.
But then the gain control is separated from the audio chain, and it could be difficult to remember, which port is which audio chain. I tried this once with a compiled matrixmixer.lv2 with 4 stereo inputs and two outputs for x64 system. The usage was only suboptimal IMO.
Yes, that was my concern. I fact, each mixer with send controls has a submix for each of the sends and those send knobs are really part of the other mixer but we conceptualise it as a function of the channel strip and may want to retain that concept.
We could add a send level control to the post-fader channel output. This would not effect the feed to the main mixbus (which is internally normalised in zynmixer) but would effect the signal being sent to other chains or direct physical outputs. It would give us a send level control which can also control a direct output like a monitor mix. It would be limited to only one send per chain and it would also effect the main mixbus feed if post-fader effects are used on a chain but I think it would be fairly easy to implement.
I would think twice about buying a mixing desk that had only one send but Zynthian is not a high-end mixing desk. It has more mixer functionality than it should!
In case I lost you there… we would have one control that adjusted the post fader send that only effects signals sent to other chains or direct outputs.
But where would that control go? Maybe we add a page to the control view. It could be hidden if not needed, e.g. the chain is not routed to another chain / direct output or maybe it is always there and we could move some other controls onto it like phase reverse, multitrack record arm, pan/balance, etc. If we did this I think it should appear in the control view page list where the fader would be, i.e. at the end but before any post fader effects and it would only appear for chains that feed the audio mixer, i.e. not purely MIDI chains.
[Edit] I have created feature request 1030 to track this.
Thanks. I think that’s kind of a compromise. Applicable for a heavy CPU-loading send chain (big reverbs, i.e.) to be able to use the reverb for more than one chain.
I like the idea with the control screen at the end. Is phase reversion post-fading? I always thought it’s on the input signal.
And perhaps, there will be another solution with more send chains later on when zynthian V17 (name: stockhausen) will be released 
.
By the way… Did I understand it correctly? What exactly is the routing ATM. Direct post fader signal goes to main mixbus, and signals from post-fader fx go to ??? not main mixbus, custom audio outputs only??? A bit confused. Sorry for asking this stupid question. I have to check it later…
Thanks for the feature request.
Check the diagram and description in the wiki. If this does not explain then I will add some more detail.
Phase reverse (which is currently available in the chain options menu) does so on the input to the mixer. This is after any pre-fader effects but before any post-fader effects.
Check the diagram and description in the wiki . If this does not explain then I will add some more detail.
I Try to explain a bit further - probably I still got something wrong.
In the workflow diagram it is not clear for me, what is the difference between pre- and post-fader effects of a single chain. This is why I am confused. Does the signal from the fader go to the main mixer input (yes or only if there is no post fader effect), does the signal from the last post fader fx go to the main mixer input (???)
I can’t find anything in the wiki about this, and also there is no content in the new ORAM wiki.
So again, what exactly is the difference between pre- and post fader fx if you look at the signal flow?
This audio routing changed fairly recently so I will have to review the diagram and description.
A chain may have audio and/or MIDI input. It may have any quantity of MIDI processors, a synth / generator processor and any quantity of audio processors, in that order, e.g. MIDI Input → MIDI Chord processor → Pianoteq → Bollie Delay. (The processors may be in any mix of parallel and series and there is no forced limit to the quantity of processors in the chain except there can only be a maximum of one synth processor.)
If the end of this chain has an audio output, e.g. it is a synth or audio chain then it feeds into a mixer input. The mixer has a channel strip that implements the phase, mono, mute, solo, fader, M/S encoding, etc. The output of this channel strip is by default routed internally (this is called normalisation) to the main mix bus. This is defined by the chain’s audio output configuration, i.e. if “Main Mixbus” is selected then this internal routing is enabled. (See below for an exception.)
Each channel strip has an (stereo) audio output which by default is not routed. This can be routed to other chains and direct physical audio outputs using the chain audio output menu. It is possible to add post-fader effects to a chain. This routes the chains direct output to the post fader effect which is then routed to the targets enabled in the chain’s audio outputs. By default this results in the channel strip’s output being routed to the post-fader effects and the output of those post fader effects being routed to the main mixbus input. The internal normalisation is then disabled.
The main mixbus can also have pre and post fader effects. If it has prefader effects then any chains routed to the main bus will use their direct outputs to feed the main mixbus pre fader effects.
It is a bit complex in implementation and can lead to some unexpected results but it is quite flexible whilst keeping the technical implementation as low-cost as we can. (Lower CPU usage.)
Idea (really just an idea, but maybe something will come of it).
If you had two (jack or LV2) plugins:
group-chain-plugin: first plugin in a (new) “group chain”. This group chain can then contain further plug-ins (reverb, delay, …) and sends to Main-Out. The plugin could have a fixed number of inputs or generate inputs dynamically (if this works with Jack/LV2 - more on this later). The group-chain-plugin has to add all signals from its inputs together and sends them to next next plugin in the chain
group-send-plugin which can be added into a chain pre/postfader and has a send controller knob that sends a portion of the signal to a selected group-chain.
If these plugins could now communicate via IPC/pipes/sockets and dynamically ports could be generated in the group-chain-plugin, you would have a flexible way of building sends to groups.
As I wrote: It’s just an idea. Perhaps discussion here would help of finding out if we can do this…
I also thought about this way after @riban’s first suggestions. If you only have one group-chain-plugin, it’s not a problem at all, but would produce a kind of side-signal flow.
What, if a second proup-chain-plugin is on a second chain? How would you separate between these two from the point of view of the group-send-plugin?
The piped connection in DSP is the direct connection within jack IIRC, or is there something more?
But yes, if it would work, would be another approach…
Many thanks @riban for the excellent explanation:
My question is now (please don’t feel confronted, it’s really that I want to understand it):
Why not simply keeping the normalisation, hence all pre-fader FX/mute/MS/solo/fader going directly to the main bus, and all post-fader signals/FX/outputs of a channel strip going to the direct output/custom chain, if choosen? Why is the internal normalisation disabled then.
If I would have both signal routes, I could have a post-fader gain “effect”, the output would go to the custom FX chain, and from there to the main bus (after signal mangling).
Hence, pre-fader/fader signal goes directly to the main bus and custom post-fader signal only to extra FX chain. If you don’t choose a custom chain/direct output → no extra signal flow.
Is it scalability (but then, where exactly?), is it phase cancellation problems (but this is already possible to have), is it, because the mixer would have 2 stereo outputs then (-> main mixbus, → post-fx)?
with love … 
If there are no post-fader effects then the end of the chain is the fader and hence internal normalisation is used if routed to main mixbus.
If there are any post fader effects they are connected from the output of the mixer for that mixer channel strip and then the end of the chain becomes the output of the last effect. So we need to disable internal normalisation and route the last audio effect to the main mixbus externally. This adds a period of latency unfortunately.
FWIW I’ve always liked “non mixer” simplicity and efficiency for the audio mixing and send stuff, probably not relevant here, but worth mentioning for the lightweightness
Non+stuff always bring good ideas:
“Each mixer strip runs as a separate JACK client. In JACK2, this can translate into the DSP workload being spread across multiple CPU cores.”
Cheers
The “non” approach is similar to how we did things before zynmixer but we didn’t have a structured approach. We could add gain plugins to a chain and route between plugins but each user had to consider how they would effectively build their own mixer with the building blocks available.
Although breaking each module out and using jack to route and sum (mix) signals gives a lot of flexibility and allows for some load balancing, it adds significant overhead by requiring plugin hosts for each module. (At least it does for how Zynthian manages plugins.) Zynmixer does some optimisation such as simultaneous processing blocks of data, not processing unused inputs and outputs, reducing latency by internal routing and processing.
I like the concept of “non” in a purely abstract ideal but would be concerned about the extra complexity and resource overhead of a practical implementation.
