blocks: how to code a clean bypass to de-allocate cpu usage [81% solved]

the title says it all.

what i have seen so far on UL:
xfade on out or .. a combination of gating/bypassing SR.

The second one is more efficiant according to cpu usage.
But how to bypass the whole structure/(or at least most of it), so it would not be part of any cpu calculation process?

big ups
dom

p.s.: i d be not only interested in bypassing a block, but any core macro in core which is not in use

 

Bypassing in instruments/ macros (Blocks) don't bring the cpu usage down a switch only.

 

coucou Paule, thank you for summarizing the subject.

 

SR bypass is the key for first approach. if I use several filter core modules to choose in one block i can route those the way each of them is onl SR active when choosen. Then Core only calculates each choosen filter core macro.

This works pretty well, but not ALL of SR info is bypassed in the chain. Means that if I use 20 filters that way in a single block - i do have the calculation of only each filter choosen, but still all filter macros applied get ADD somehow in calculation curcuit.

My thoughts are:
maybe every macro (inside its surface and sub structure)... could be controled by bypassing SR.

 

the xr gate story is baffling me to.
why isnt it part of the blocks framework?

 

OK this is probably a work around to get most of your CPU back home:

here is an example on DWG Osc. Create Distribution, call it SR. Now every core macro which uses sample rate shows up in red.




add XR Gate (for those who are not familiar with: core manual somewhere around page 94)
create a new distribution bundle which converts SR into - let's call it SRB



now tell every red core macros from step one to handle their SR distribution by the new SRB



and that is probably the fastest way.

i also add a bypass on mod A and mod B as well clk display distribution. now they are all linked by XR Gate and on if G is 1.

Ill attach the bypassed DWG version. On my system it bypasses from around 2% usage to 0.2%

That's so far pretty good. In future, i d probably like to know how to bypass e.g. display calculations in panel...
but for now
dom

 

i didnt mention that disconnecting the outs in core would do the intire job of bypassing the whole block.
but disconnecting those outs with "0" doesnt do the trick.
guess this is due to the core structure priorities.

so please enter some messages here to get NI (NATIVE INSTRUMENTS) involved on REAL BYPASS CURCUIT.
OM H
HO
Holy OUT

 

I also didnt mention that 2% vs 0.2 % sounds like not much of a story.
But CPU increases which each instance (even not wired) presque (french for likely) doubled. WHY?
means: I can have 5-10 nice blocks.
but 15-20 increases CPU like inbetween lin exponential.
And I cant stop the out with "0" inside of core, to be calculated.

alright, hope this was "educational" enough.
NOW ITS UP TO YOU DO ASK FOR A REVOLUTION

 

All that editing is unnecessary, just stick this at the top level of a core cell if you want to gate the SR clock:



Note the double period starting the SR input! that tells Reaktor not to complain about feedback, which allows you to override the named distribution so you don't need to go editing all the individual child macros.

Personally, I don't like the idea of an on/off disable switch - just going to cause confusion for the most part. Just delete blocks you don't need and there's no problem

 

i didn't know that as you would guess. and hell you made it again!

thank you col(in)!

but now you say:

i respect a 100% your personal oppinion. (but i dont get it into my mind for all scenarios)
me, i do think a dsp modular should work the way it is used. - yes in terms of cpu usage unfortunately.
why would you be against that?

in a single patch i would love to have this reverb on preset 1 and the other reverb ond preset 2 - without adding each other on calculation/cpu.


(and just for those who would love to bypass all circuit calculation: is there any possibility to bypass the out of core as described before, so it would not attack calculations/cpu at all)

and thanks again colin for this advice!

 

hi, sorry i have to roll it up.

in the past i thought that it would be fine not using a smoother on BYPASS in this configuration.
cause otherwise /or in the case scenario i thought :

1st: it wouldnt work – the BYPASS smoother is controled by its SR mothership as well
but then i of course thought:
you can easily get rid with it while adding a second distributor (still from its "SR mothership", but:

2nd: if i control all and every smoothers and bypass itself on the first main SR distributor, they are still all hanging on a single SR
- so, reactivating them would cause an "explosion" anyhow ??!!

then i thought:
maybe reactivating the bypass needs another slower smoother than the 1k - 15k
but i couldnt help myself. bypassing with xr gate integration and another sr distribution on the fade and smoother still end up in the famous "click" (which also often appears by just changing snapshots while playing.)


the smoother 15k (2) in this picture is only reacting on smt 15k which is sr distributed by sr"2" . so sr"2" is entirely individual of all other xr sr bypass. but it doesnt work/still "clicks"

and im not sure if it is possible, but i think the nsmooth macro could play a big role, it is just not working properly in this scenario. it is more "fading"

 

You haven't explained what the problem here is. Or what your questions is...

 

i am trying to smooth the bypass knob/switch in this particular structure - where bypass triggers SR Gate of most macros in the structure.

In this case the block is an eq and in serial. Means that there are blocks before and after. Yet while switching bypass, i get pops and clicks as if the switch wasnt smoothed at all.

 

Ah, ok.

You don't smooth clock switching.
Instead you need some sort of fade out/in structure.
So that when you hit the bypass switch, it first fades out the output of the module, only then switching off the clock. Then when you switch on - you switch the clock on, then fade in the output of the module...
It's not a smoother!

 

YOU RE JUST A KING! WORKS! what i did wrong in the setup above was that the fader faded after the clock switch and not in between like you said. Thanks so much, Colin!

 

btw, is it possible to use the same for snapshots in global ens directory to prevent them from popping/clicking while switching in between those (and while playing) ? i think i saw some "addon" once in the UL