Operator feedback in the scheduler event domain

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.

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.

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.