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

Managed to get the multidisplay doing it' business using iter as clocksource in gui thread core cell
Phase mod works , implicit feedback does not

Ofcourse I must be doing something wrong ….

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

Also how can I pick up the new C.R. without being a bundle , iow staying in the same hierarchy level ?
Have to say , that gui reclocking is a pretty nice technique

colB

https://community.native-instruments.com/discussion/comment/233328#Comment_233328

You are creating a new distribution bundle called new, Then sending it into the clock bundle input of the FM Op. That will override the SR bundle inside that macro. Poblem is that the implicit feedback is outside of that scope.

If you change the name of that bundle to SR, it should work

you can disconnect the input of the SR input of the FM op too, the wired connection is not necessary if you are overriding SR in the parent macro.

colB

pic to illustrate

colB

Here's what I have (Maximum simplification as requested). In a real situation, I would keep ranges of displays etc to 0..1, but that would bean some scaling and offset in the core cell.

gentleclockdivider

Awesome , thanks for the guidance !

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

colB

With this approach, you can use implicit feedback (As I've said, I would avoid that. It is better to control the position of the unit delay and it's clock explicitly…)

NOTE on why its good to treat orange wires as warnings:

Those orange warnings wires can be very useful. You might have a complicated feedback path, and you think it's all correct, you've placed the explicit z^-1 macro… but you still get the orange warning wires! That tells you there is a problem in the code, an extra unwanted implicit unit delay is hiding somewhere.

If you always just use implicit, then this doesn't work, you can't tell the difference, because the wires are already orange, so the error in the code goes unnoticed.

These errors can cause various problems… filters might become unstable, or have bugs in the frequency response… FM feedback might not sound like it 'should'… you could get unwanted artefacts in the audio that are very difficult to isolate…

gentleclockdivider

Fun Fun fun

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

gentleclockdivider

https://community.native-instruments.com/discussion/comment/233332#Comment_233332

That part I had already figured out , I was justhaving some troubles with the reassignement of the new clock source , mostly naming conventions .

gentleclockdivider

There is still one thing that's unclear

Say I want to rename the new clock source ( as in the previous example ) , the feedback doesn't work since it's outside of the scope .

Using a bundle to connect to the new S.R . , but inside the macro i have no idea how to connect it to new Clock . Since it's a bundle it onle sends it deeper

gentleclockdivider

Pretty confusing , I got it connected to the new scope called " nwe " but no feedback , still says implicit
The mem read is triggered by sr.c

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

All because of some new Clock naming

guiclock2.ens

colB

The 'scope' of some construct is any code that can 'see' that construct.

The 'scope' of the distribution bus is the context in which that bus is active.

Here are two examples:

Example A:

Here the new clock is packed, and fed into the SR input of 'child macro'. That new clock will have no effect on the macro called 'generator'. Generator is outside of the scope of the new clock. The new clock only applies inside 'child macro', and any of it's layers of child macros.

Example B:

Here the new clock is packed and then distributed as 'SR' this causes the default SR bundle to be overridden… the scope of this new version of SR is everything within the macro 'example B', and all of it's children down the layers, including 'generator', all it's sub layers, and 'child Macro' and all of it's sub layers.

Any reference to SR.C, or SR.R in example B, or any of the macros it contains including 'generator' and it's entire sub structure, will use the new versions of SR,C and SR.R.

The only time this changes is if another sub macro overrides the same bus. In that case, everything at that scope and nested inside it will then follow that newly overridden version.

NB. You can use double period notation to reference the BUS from the outer scope, which is sometimes necessary when overriding it:

'child macro' now sees SR from the parent scope, instead of the newly overridden SR, because it is connected to '..SR' (generator still sees the new version).

This mechanism is most common in Library macros that have an SR input bundle. Those default to '..SR' if they are unconnected, Here is the factory sawtooth as an example:

That ..SR input on the SR bundle input tells it to default to the SR from the parent scope if it is unconnected externally. If it tried to use 'SR' without the double periods, it would try to default to the SR distribution BUS attached to it's own output, causing an error:

This stuff seems complex at first, but once you understand it, it is pretty simple, and quite useful. It makes Library macros more flexible and easier to use. Like the example in this thread, using macros built for audio, but in a GUI context, with no editing required. Magic!

Distribution busses and reception busses are very useful, but you need to develop a basic understanding to exploit them effectively.

colB

Just to be clear, you shouldn't be renaming the clock bundle. It should be called SR.

If you try to rename it to 'new', then you will need to go and edit the entire structure of every macro you use, editing all references to SR.C and SR.R to become new.C and new.R. That completely defeats the purpose.

The whole idea is that we keep the name!

We override the existing bus with that name, so that it means something else within the scope of our new definition. Then any library modules active within that scope will auto-magically use the brand new clock we just invented, even though they were written years before our new clock was ever imagined.

gentleclockdivider

It is a bit confusing
You say that we shouldn't rename the clock bundle because otherwise we should rename everything deeper donw the structure
Are yuu sure about
If I call the master clock ward like this

I go into the sine osc and pick up the distribution buss "ward"

This bundle input is connected to a new distribution bus called SR , so that establishes the build in SR.C. connection

And everything deeper down the structure will conncect to SR when right clicking an input and choose from the context menu "Pickup std distr.bus ( which can NOT be changed )

BTW , did you have a look at the ensemble posted Guiclock2 ?
Afaik , evertyhing is connected correctly wiht the new naming but no op. feed at all
The macro is correct since i's actually a simple gain multiplier , showcased in the first part of the giff , then as a feedback multiplier which it doesn't do

https://i.imgur.com/1eiOd37.gif

colB

If you are editing a factory component for basic functionality, then you are probably doing something wrong.

If you want to override the clock, but don't want to create a distribution for that, just pack it and wire it to the SR input on each macro that needs the new clock.

Seems like unnecessary work to me, but hey, you do you :)

Quick links

Unanswered questions