MUX: Remote controll of the process button
-
- KVRer
- 3 posts since 16 Dec, 2003
From Cubase, I see that I can remote-control the metaparameters of the modules inside a MUX patch. Is it possible to remote control the "process off/on" button of a specific module, for example the Stereo Splitter?
I couldn't find a way to map it to a metaparemeter.
Thanks
X:
I couldn't find a way to map it to a metaparemeter.
Thanks
X:
- KVRAF
- 13863 posts since 24 Jun, 2008 from Europe
No that On/Off switch is not automatable. But you could setup a bypass using a balancer module and automate the balance.
- KVRAF
- 7412 posts since 8 Feb, 2003 from London, UK
Interestingly, the Mixer Strip module has a mute button that can be automated.
(the "after movie" frame on youtube makes me want to just use the version on my local server...)
That may feel more intuitive in some circumstances.
(the "after movie" frame on youtube makes me want to just use the version on my local server...)
That may feel more intuitive in some circumstances.
-
- KVRer
- Topic Starter
- 3 posts since 16 Dec, 2003
Thanks for the tip, will try this; please consider this feature as a simple addition to the next MUX development cyclemutools wrote:No that On/Off switch is not automatable. But you could setup a bypass using a balancer module and automate the balance.
- KVRAF
- 13863 posts since 24 Jun, 2008 from Europe
The On/Off switch is like a power outlet and not meant to be automated. It would be like plugging in and out your TV several times per second. That's not the goal. If you want to automate a mute or bypass, that's possible using the ways indicated above.
- KVRAF
- 7412 posts since 8 Feb, 2003 from London, UK
Quick question on this. Does "Mute" actually just set Gain to -oo? (That is, does any optimisation happen - similarly, if the pan/width are default?) If it's still running most of the processing, then the simpler control the better. "Send" looks like it probably does less processing than either of the "Balancer" modules (input -> send out with the send level automated; there's no cross-fade processing).
- KVRAF
- 13863 posts since 24 Jun, 2008 from Europe
Euh yes that's mathematical equivalent.pljones wrote:Quick question on this. Does "Mute" actually just set Gain to -oo?
Yes that shoud be in most cases.That is, does any optimisation happen - similarly, if the pan/width are default?
Not sure if i fully understand. Are you saying there is an issue somewhere?"Send" looks like it probably does less processing than either of the "Balancer" modules (input -> send out with the send level automated; there's no cross-fade processing).
- KVRAF
- 7412 posts since 8 Feb, 2003 from London, UK
No issue. A very simple question. Is there any benefit in picking a simple module over a more complex module in terms of performance. The comparison I gave was between a module (Mixer Strip) with four controls - mute, gain, pan, width - and one (Send) with just one control - send gain. The Audio Balancer module also has four controls but one of them is a curve selection, which is likely to mean further computation.
The comparison is between "If (a == 1) { return n; } else { return n * a; }" and "return n * a;". In the former case, an optimisation is performed dependent on the parameter "a". In the latter case, the maths is performed regardless of "a". (Ignoring subsequent lower level optimisation that certainly happen in that example, of course. I don't know how much of the audio processing maths would be that trivial.)
Clearly, where a large number of modules are being used, the lowest CPU usage per module is desirable. (My main use is in highly complex MUXes of which I then use around 70 copies concurrently.)
The comparison is between "If (a == 1) { return n; } else { return n * a; }" and "return n * a;". In the former case, an optimisation is performed dependent on the parameter "a". In the latter case, the maths is performed regardless of "a". (Ignoring subsequent lower level optimisation that certainly happen in that example, of course. I don't know how much of the audio processing maths would be that trivial.)
Clearly, where a large number of modules are being used, the lowest CPU usage per module is desirable. (My main use is in highly complex MUXes of which I then use around 70 copies concurrently.)
- KVRAF
- 13863 posts since 24 Jun, 2008 from Europe
Generally a more complex module uses more cpu indeed.pljones wrote:No issue. A very simple question. Is there any benefit in picking a simple module over a more complex module in terms of performance.
But you add an IF statement which can be costly, dependent on where it is used. Optimizing is a special art and also very CPU architecture dependent, even within the Intel range. So an optimization on system A might be bad on system B.The comparison is between "If (a == 1) { return n; } else { return n * a; }" and "return n * a;". In the former case, an optimisation is performed
Anyway, MuLab and MUX try to avoid redundant computations.
