Turning audio macros on/off without using switches

Hello,

I have an ensemble with some stereo audio macros wired in parallel and I want only one at a time turned on to save CPU cycles.

A pair of ganged switches (one for L, one for R) will do the job, but instead I want to use an event signal to do it.

Is this possible? I can't figure out a way to make it happen.

 

Core or Primary?
What you are asking is relatively easy in core, but I don't think it's possible at primary level.

 

It's a hybrid. Each parallel circuit contains a bunch of primary-level macros that drive a final audio core cell. If it helps, most of the primary-level stuff handles events, not audio, and the primary-level audio stuff can be moved into the core cell.

If it's relatively easy in core, I'm interested.

 

You can use optional clocking in core

http://www.nireaktor.com/reaktor-tutorials/optimization-in-reaktor-core/

 

The only real gotcha is using library macros. You have to go through every level of the macro removing SR.C references, and replacing them with a clock that you pass in at the top level. If you get this right, you can turn them on/off by routing a clock to them or away from them.
You can use the audio stream as a clock and dispense with the additional lock inputs, however, I like to keep the clock separate so that the functionality is clearer.
Large sections of core can be switched on and off in this manner without significant overhead.
Get used to using latches - they are crucial to getting this working without having to do a lot of re-writing... e.g. after you have got rid of SR.C references in the code. You might still have multiple inputs that each have audio or event streams. You need to ensure that these are stopped when the clock is not running. Use a latch driven by your clock (or your separate event clock if you need event rate functionality).

 

it's also important to remember that the z^-1 macro has an SR.C connected to one of it's inputs by default... that's a really annoying one that's gotten me a few times in the past.

i also find that using the audio stream as a clock source is a bad idea - i can't explain exactly what happened without posting an extraordinarily complex core cell, but it can cause problems with event orders in cells using feedback, in my experience.

 

I just had a look at Salamanderanagrams link, and I do it slightly differently.
Here's his example:

The Clk input is really a flag rather than a clock, and it is used to switch on/off an internal SR.C stream. You would add this switched SR.C trick where-ever you need a conditional clock.

My approach is to replace the SR.C of the original with my own clock input (actual clock events rather than a flag) like this,

I pass my clock connection through the layers of my core sructure, and setup a selective routing for the clock stream at the point in the structure where I need to switch between different blocks of code.
Macros that I would like to reuse - like filters - never have an internal switched SR.C reference, instead they just have a clock input.
For this method, you only need an SR.C at the very top level (and even there, it's only really needed if you don't have an input audio stream).

 

I've never had a problem like that. I do sometimes use the audio stream as a clock, I just make it clear by naming it as 'In/clk' to clarify that it provides both functions.

 

to be clear, i'd certainly use a method like you outlined for anything more complex than a single macro - it's certainly more efficient that way. typically i use clocks to turn off un-used voices, but they can also be great for multi-routing ensembles like the finger or optimus prime.

the trouble i had with using the audio source as a clock was in a zero delay filter that had an added saturator in the feedback path (yep, finally cracked that!). i was having lots of problems at that point in time (am i implementing this math properly? is the math even right in the first place? etc) so i can't guarantee that was the problem, but i think it was. i think the core macros with the 'solid' parameter unchecked may have caused it.