Operator feedback in the scheduler event domain

gentleclockdivider

Thanks Col.b . I got all that .

The thing that I struggled with was the old SR.C and SR.R but now I completely understand it .
The acces to SR.C and SR.R can not be renamed , but the fibers that are referencing them can ,which are then appended after the bundles'distr.name .

It makes sense to keep the bundle distribution named "SR" for compatibility's sake and so that old ensembles have acces to it .
The pick up distr.bus for the fibers should be prefixed with .. when the distr.bus is called SR ( to override it

On a side note , to get Yamah style operator feedback , the feedback amount is averaged .
In primary I used this , added the implicit feedback + explicit

I get the same result in core , don't know if it's correct but it does the job wonderfully
Two pairs of write read , the feedback is 99% the same as the old yamaha's ( referencing my TG77)

This is really how the (yamaha style ) op-feedback should sound ,

15-07.ens

And a nice superimposed graph
Red = modulator ( operator feedbackk ) Phase modulating
White = Carrier
Also , thanks a million for showing this neat graphics trick , which the thread was initially about

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

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).