Battling CPU
It seems the latch might be your best friend in turning off a module. As shown below I installed latches on all inputs except the reset. The clock for the module is turned of externally but without the front latches a lot of things were still active. It seems the latch cannot send out an event with it's clock stopped. So any additions or other math functions are not triggered and do not perform calculations. The cpu dropped from 30% down to 24% after adding the input latches compared to a previous turned off method without latches. This is a screenshot after the input latches were added. The adder and log module already have built in latches. The SR bundle distributes the audio clock. After stopping the clock and using the debug tool everything was dead still. Before adding the latches the adder and other things were still running so the latch must no longer produce an event to trigger any downstream math.
This is the insides of the adder module showing the serial clock.
Let's have a quick look at the inside of the latch and see why this works. The write module receives the input and the read module will not send out an event unless it receives a clock event. Since the cpu dropped 6% it seems positive proof that within reaktor, everything must receive an event to start performing a function. So stopping unnecessary events is key to reducing cpu.
The above module is driven by an envelope generator. I have rigged the envelope generator to stop the clock of this module during the final release phase. So why leave this running when it produces no sound! It's important to realize the values of the memory are maintained when the clock suddenly stops. This can leave outputs with a non 0 value. So in this system the outputs are muted by the same event that stops the clock as shown below.
Notice the pickup distribution bus labeled stp1. stp1 is a 0 value sent from the envelope generator when it decays below -60db. Since this is the main audio output module it's also the first to be zeroed before the clock actually stops on the next cycle. In reality the audio is already reduced by 60db and terminating it does in fact create a spike but is very hard to perceive. As a side note, stopping it early when you can't hear it also saves cpu. So being practical helps too.
Comments
-
This is not a great practice--what you're doing here is resampling all of the inputs at audio rate; this is harmless enough for audio signals, but for signals either running at a lower control rate or for intermittent momentary events (e.g., from buttons, knobs, etc.), all you're doing is needlessly generating hundreds or thousands of extra events per second, per input, that propagate throughout active structures downstream. Apart from structures in which all of those inputs are actively passing audio-rate information--in which case a single XR Gate ought to get the job done--I'd generally expect to see an increase in CPU consumption from active modules.
There are places where it's useful to use these sorts of reclocking latches, e.g., when combining audio- and control-rate signals elsewhere and wish to prevent the passage of additional/interstitial events per clock cycle (since audio is necessarily clocked via SR.C, but events can occur at any time arbitrarily, and the control clock is asynchronous with the audio clock); but misconstruing them as a "magic bullet" for unwanted CPU consumption is a mistake that's likely to backfire.
If you are experiencing higher than expected CPU from a core macro with it's internal SR.C off, it's because something upstream is erroneously feeding one or more of the inputs with an event stream and the macro is processing them insofar as they run into a clocked structure. You're better off identifying where that is occurring, and latching it off appropriately rather than just resampling all of the inputs higgledy-piggledy.
0 -
this is harmless enough for audio signals
It could even be beneficial in some circumstances! (e.g. where the wider context is not ideal)
Latching all those inputs to SR.C tells the compiler that it can just use audio clocks for that whole part of the code. If any of those inputs have mixed event source (some are from external non audio events, or some complex graph that the compiler can't easily unravel) then clocking in this way could improve things, and assuming the code that it is feeding into is running at audio rate, it shouldn't cost anything because the compiler recognises and optimises the latch pattern, but it seems like a hacky approach...
A better option might be to use mod math macros in the correct places. That puts the latch pattern exactly where you really need it. It also results in cleaner code.
0 -
Thanks for the reply Colin. Those mod math macros are an excellent resource. They simply do not produce events that can travel downstream and retrigger gates among other unwanted events that do nothing but waste cpu, good point! This application was intended to shut down a complete module. I can picture using modulation macros but I'd have to contemplate how to do it. Normal mod macros would not work in this case as the input event itself is what clocks it downstream, so there is no way to stop it with the master audio clock turned off. Perhaps the tap macros may work as I think they work backwards from the mod macro's. Where as the lower input actually clocks the upper input through. Not sure, need to study them more. In this case, I needed to shut everything down and it worked as expected. There is no activity in there because all inputs events are not clocked thru. So there is no downstream processing wasting resources. I had to do this to get more voices in my fm synth. It works quite well because none of the operators have the same envelope. As soon as the envelope decays to -60 db a comparator shuts off the entire operator and ultimately allows more voices. I'll check into the tap type of mod macro's, hopefully it'll make better code if they can do the job and kill two birds with one stone.
0 -
I see your point about resampling event inputs. Luckily there are only a few event inputs there and I might be able to remove those latches and tie the events into a modulation macro and keep the audio latches. XR gates are pretty cool when used with factory modules. The dev's are pretty sharp aren't they. They optimized their modules to be shut down and reset with the XR. The more I get into Reaktor the more I learn, Thanks for the pointers. I'll see what else can be done, this was just a hacked test to see how much of an improvement. Even though it dropped 6% it would have dropped more if I hadn't resampled the event input. I think five of them are event inputs, so I just need to us mod macros on them. Thanks
0 -
Ok Colin, I revised it with mod macros. It works perfect!!!
I can't delete the pic below, anyone know how?
0 -
As a side note, I see your point about stopping things upstream. The dup filter is good for that.
0
Categories
- 12.1K All Categories
- 21 Welcome
- 545 Hangout
- 66 NI News
- 264 Tech Talks
- 1.2K Native Access
- 5.7K Komplete
- 727 Komplete General
- 1.3K Komplete Kontrol
- 2.1K Kontakt
- 564 Reaktor
- 181 Battery 4
- 313 Guitar Rig & FX
- 220 Massive X & Synths
- 261 Other Software & Hardware
- 2.6K Maschine
- 24 Sampling Room
- 3K Traktor
- 2.8K Traktor Software & Hardware
- Check out everything you can do
- Create an account
- See member benefits
- Answer questions
- Ask the community
- See product news
- Connect with creators