Help wanted - building a dispersion Block

delete

 

From a quick look at the images, the downstream stages keep on running because they have SR clocks inside (the filter & delay). To make them turn of you'd have to run the SR clocks through routers as well. At least that's what I remember having to do in a similar situation once.
Of course turing of the clock into the delay might be problematic when turning it back on if the delay line is not emptied, so that might need some extra work.

 

The XR-Gate from the core library can gate the SR. The picture explains it all

 

Hi Jim,
also had a rough look.
As Leon said, it might be a good idea to turn of not needed stages.

But i saw some other heavy things regarding CPU consumption:
The variables coming from the macro "band coefficients" are all SR.C driven (Sub macros "clk select")! That is absolutely unnecessary. The variables will be set once at Initialization or when changing the "style" parameter. A lot of Compare/routers are driven by SR.C.
Downstream, in macro "Disperse Tune Octave", several maths are done at SR unnecessarily, too.

Using Quickbusses in Macro "Disperse" would simplify the copy process of the "Disperse Tune Octave" macros alot ;-)

cheers mark

 

By the way, in the macros "clock select", i would compare GREATER not EQUAL, because it uses less CPU

 

Again, i´d love to see Reaktor Core showing SR clocked wires in another color...
Blue: normal Audio path
Red: unnecessarily SR clocked variables and maths

 

I´m not 100% sure what you mean, but this could be a problem of comparing (Equal to) floating point numbers.
As the stages parameter from primary only contains integer numbers (in float precision), you can -and should- safely convert it to integer precision in Core.

 

Uff, a lot of stuff
I take the gated SR.C by side for now. I also noticed a very long compiling time while trying to implement some XR GATE.
I´ll go on with the selectors.
I don´t know exactly what the advantage of the GREATER comparison vs. the EQUAL comparison is. I just read about that somewhere and it belongs to the machine where the code is running, i think. Besides, it might not be significant if it´s only calculated once or unregularly. But at SR this could make some points!
So, for the selector you could use the GREATER tree.
No Clock is needed here, because the sel input itself is the trigger for the latched constants at inport 0 to 9.
I think you still didn´t arrived in the simultaneous world, yet? ;-)


Alternatively, Partial Frameworks comes whith several selectors and routers using another approach:


And here comes the smartest solution for your need:

pack all the constants into a core table and read them out by Sel.
It can´t be simpler!

 

The Routing Macros in the first picture of my last post are the same like the "IRouter GT" from the factory library. I just don´t like the new symbol, because it´s much toosmall for my eyes

 

Just want to add that your selector solution is OK (with possibly enlarged CPU consumption?). But replace the clk quickbus at the most upper router by sel! Than the result is the same as with the tree selector i showed up.

I just realized that the Partial Frameworks Selector is triggered by the event inports, not the Index inport []. You need the Index triggering an event inport.

 

That is correct! Audio signals, Clocks and Events behave all the same in Core. There is no logical difference. The only difference is when those events arrive or will be generated and how often in time. That´s a big point in Core. I speak of events also for audio and clock signals here.
What you often have to take care of is, if events are synchronous to SR.C or not. If not, than they are asynchronous. Asynchronous events definetely come from Primary event sources. An asynchronous event at ONE core event inport spreads simultaneous over all it´s branches in core. Means, all downstream structure of that ONE inport is calculated simultaneous. I.e. an Add module, fed by one source event at both inports will give only one resulting event. Not two, like in Primary! Only the OBC Memory Master Slave connections lead into a logical order in which memories will be read out or will be written to.
Events in core that are synchronous (to SR.C) come from an Core Audio Inport or are triggered, latched, generated by the Core SR clock (or sub clock) in some way. Everything that happens at a clock tick is simultaneous, also (and synchronous). If you know all your synchronous outports, wires and modules, it is relatively easy to figure out what happens in your core structure. This is not the case for asynchronous events, because you often don´t really know when and in which order they come (Primary style).
Additionally there might be a Thread separation here also between synchronous events and asynchronous ones?

INITIALIZATION in Core (Ens Load, Power Off/On, Sample Rate Reset):
EVERYTHING in Primary and in Core is simultaneous! If i´m right, the audio part in primary and with that Core Audio Inports are firing, also.
Constants in Core fire.

RE-INITIALIZATION (Switch, List, Reveive, structure edit in Primary...)
short: no initialization in Core, no core constants fire an init event. The simultaneous primary init events appear ASYNCHRONOUS FROM TOP TO BOTTOM INPORT in Core.
Core Cell Outports will be forwarded to Primary simultaneous again....

 

coming back to your selector the simultaneous initialization means, that the Core Constants and "sel" coming from another Core constant or the primary list module named "Style" are simultaneous also.
So, because Latches have defined first write than read order, the sel trigger will read out the correct constant value at the corresponding latch.
That´s it. Later on, all Latches are still filled and can be read out as well.

Another very useful macro you´ll need often for synchronizing asynchronous events to any clock is the smart value. I thought i saw it under another name in the library, but can´t find it anymore. The structure looks similar like this:


Inside the macros "0" and "1" just a zero or one is written into the memory chain.

Yes, that´s still annoying. Even not the simple counter is included anymore...

 

Not sure what you mean. The SR.C pickup itself i.e. always fires zeros only.

Yeah, i don´t no. That´s my question! Max told us in his Thread-safe documentation something about a Audio and a GUI thread.
A longer time ago i did some tests and came to the conclusion, that core in itself is thread-safe. But i´m not 100% sure.
So, Primary events must be in GUI or Audio thread, depending on the triggering source (Midi, Mouse, PC Keyboard, OSC, DClk, CR...)
Core seems to convert to Audio thread. Not sure...

 

it is part of partials framework:

@Jim: ”!” is the clock input in partials framework

 

There aren't many changes. I will have a look into it. Don't worry about it -
only small changes i think.
Ciao herw

 

If FBoost is 1 (or greater 0), you can save 10 comparisons at sample rate per stage.

 

wow, yes you got it

 

Hi Jim,
have a look into your eMail account
ciao herw

 

It´s my pleasure, Jim