Operator feedback in the scheduler event domain

gentleclockdivider · 2025-07-04T22:27:03+00:00

There was an error rendering this rich post.

This is mostly pure for visual and educational purposses and it's happening completely in the event domain no audio whatsoever , sadly this is not possible in reaktor because it requires a feedback loop.
The typical aliasing that occurs when an operator is fed back to itself , turning it into a saw and eventually collapsing into noise .

I tried an event delay in the feedback loop , but no luck
Reaktor versus pure data
Pure data can handle feedback loops thorugh iteration , even in the scheduler domain
Showcase 2 operator fm strucuture , modulator fed back into itself

Not really a big deal but it does put ahalt on how far we can take the pure procedural gui processes

https://i.imgur.com/5qStoJi.gif

Pure Data

https://i.imgur.com/E00tzj8.gif

Find more posts tagged with

Comments

gentleclockdivider

Well even better ( for me ) instead of using the gui rate to trigger the iteration , let the gui knobs do the itter job
This way the scope ( multidisplay ) stays stationary , and that's what I wanted inthe first place
Thanks a million times Colb , this is bloody Awesome

https://i.imgur.com/Qg7uwIM.gif

KoaN

https://community.native-instruments.com/discussion/comment/233515#Comment_233515

The latch[-1] in the library is always non-solid and the info states it is made for feedback structures. I always use this to get rid of orange cables,this way i decide where the z-1 happens.

colB

https://community.native-instruments.com/discussion/comment/233515#Comment_233515

There was no need to another macro with z-1 , since the"Hello" macro was just a gain multiplier ( also functioning as feedback coeff ) .

Yes, initially, the 'hello' macro was just a multiplier - everything else in there was completely redundant.

So in the end , the renaming was done correctly

There was no renaming. You packaged up a clock into a bundle, and put it on a bus, and gave it a name. You didn't rename anything. There is no renaming happening. Renaming busses is not a thing in Reaktor it's literally not possible.

If you change the name on a scoped bus distribution module, you are telling the bus distribution module to start distributing on a different bus. If that bus doesn't exist, it will be created.

(If this seems like a pedantic distinction to someone, then they don't understand how busses work in Reaktor)

Generally, there is nothing wrong with creating a clock and putting it on an arbitrarily named bus, it's a useful technique. However in this specific case, it's non-optimal, and particularly in the context of your code from earlier in the thread with implicit feedback (that you couldn't get to work, and were asking for help with) it just doesn't work, whereas overriding the SR clock does work.

All that was required was non solid mode fo r the "hello "macro
and to get rid of the implicit feedback ,reverse OBC of write read order to get an explicit 1sample delay
inside the "hello " macro

hmm… all that was required to avoid using a z^-1 macro was to turn part of the hello macro into a z^-1 macro… seems like a perversely contrary solution?

which of these two pieces of code is more immediately understandable to others, or particularly to the author in two months time?

colB

https://community.native-instruments.com/discussion/comment/233632#Comment_233632

Not really.

If you make a macro non solid, it means that everything in the top layer inside the macro is in the same scope as the parent macro.

A non solid macro is like you cut everything from the macro and paste it into the parent.

colB

Please try to remember that just because you don't know how to do something in Reaktor doesn't mean it can't be done (often easily) in Reaktor.

Maybe instead of posting:

"Reaktor can't do this thing, but pure data, max (whatever) can"

Why not:

"I'm trying to do this thing in Reaktor, but I can't work it out, can someone tell me how"

colB

A very quick example.

gentleclockdivider

Not working over here
SOme guidelines would be appreciated , no uploads please since I'm still on 6.4.

https://i.imgur.com/lHQKboZ.gif

colB

https://community.native-instruments.com/discussion/comment/233238#Comment_233238

indeed…

Things to consider:

Phase modulation and frequency modulation are not the same.

Orange wires in core are a warning.

gentleclockdivider

Why are you even implying that I don',t know the differnece between phase modulation and frequency modulation , i'm not frequency moduating anything , how do you even suspect that ?
It's calculating the cosine function of a linear ramp from the iterator , feeding this back into the cosine is operator feedback phase modulation
See the pure dat screenshot ..that is PUre phase modulation and operator feedback and the exact same principle , and also have a look at the numerous ensembles I've uploaded ..

https://www.native-instruments.com/en/reaktor-community/reaktor-user-library/entry/show/15517/

https://www.native-instruments.com/en/reaktor-community/reaktor-user-library/entry/show/8291/
I appreciate your help and knowledge verry much but sometimes you're assumming I'm a complete noob .
And yes orange indicates a feedback loop , which is what I want in the first place , I could insert a z-1 and maybe that 's needed becasue of the gui only process .

I tried to replicate the exact same steps in reaktor versus pure data , so if you have any tips , you're welcome .
Phase modulation in the audio domain , shown below with the dreaded Primary ;)

colB

Confirmed. Reaktor will default to using the SR.C clock to drive the unit delay in an implicit feedback loop.

gentleclockdivider

So how did you do it then ?
Once again , now in it's most basic form, olnly ONE operator

Pure data : iterator ( 512 ) / 512

Then an expression module 2pi*iterator output
Calculate cos.function

Feed cosine back to itself ( and thus modulate the phase of the integrator-ramp wave )
Exact same procedure in reaktor , everything except iterator is done in a core gui cell

https://i.imgur.com/9NeCn7p.gif

https://i.imgur.com/s9YvA6X.gif

gentleclockdivider

Is the iterator outside the core cell ?
I can't even get the bundle distribution to light up

It seem slike a overly complicated task for what is n esence something verry simple
Why are the objects even iterated , set to ( -6 line ) only once should do the job , no ?

colB

That code is also rendering the waveform

gentleclockdivider

Well that was the point of this thread .

Rendering only requires index and two coordinates x1 , y1 ( when set to line )

Either way , It's not a straight forward process and I am still not getting any wiser - getting this done in core

colB

https://community.native-instruments.com/discussion/comment/234173#Comment_234173

but the fibers that are referencing them can ,which are then appended after the bundles'distr.name .

Yes, it's a bundle distributer, so we can override it and put any bundle we like on it, with different fibre names (really different fibres), different numbers of fibres etc. Although that would be silly. Why would we override an essential core mechanism in a way that prevents it from working correctly?

Personally, I love the distribution bus system, but I find the bundle system less than ideal, there are things I think could be better in there. I suspect it is the way it is because it was just the foundation of a more powerful system that just never got completed… potentially with iteration, code re-use etc. Vadim hinted at this a few years ago.

Reception busses are mostly useful for debugging (fantastic for this!), and for patching new functionality into large, deeply nested structures quickly (using distribution busses for the input side, and reception for the output side).

Quick links

Unanswered questions