Scoped busses , description is so confusing
SO , the description of the distribution bus is as follows " Sends the incoming signal deeper into the stucture . "
With deeper I assume ,core macros within core macro's .and the distribution is located in one of the top macro's and thus sending it into the nested macro's where the Reception bus is located .
Now , the reception bus description " Receives signals being send from DEEPER area's of the structure .
This comes over as a paradoxal , how can it receives signals being send from a deeper structure , if the signal being send from distri.b. is at a higher level ?
Comments
-
distribution sends to current level, macros within that level, and sub macros of those...
Reception receives from same level, or macros and sub macros within that level
There is no paradox.
Just have to understand that Distribution and Reception are different things a distribution does NOT send to a Reception, and a reception does not receive from a Distribution.
Also, events from a Distribution can be picked up in multiple different places, however if you try to send to a reception from more than one place you will get an error (obviously).
To use e.g. a distribution bus, create one, name it, connect it to an event source (module output etc.), then right click on an input somewhere in the (sub)structure and choose 'Pickup Distribution Bus... from the dropdown:
To use a Reception, you right click on an event source (module/macro/inport output) and choose 'Send to reception bus'
Distribution is handy to avoid the hassle of working down through layers of macros creating inputs and outputs and connecting them up, just because you need to add some new external parameter (If you forget where they are connected to internally, just rename by adding XX or whatever, then all the macros referencing it will turn red because they don't have the correct name any more).
Reception is most useful for debugging. You set up a top level output latched to the display clock with a reception bus (called dbg usually), set up an external numeric or scope or whatever in Primary, then you can easily send to that from anywhere deeper in the structure. Makes some debugging tasks really quick and easy when they used to be a huge amount of work!
1 -
It's still confusing
See this mac , i have three event output and I want them to receive values from the macr
I righclicked the input of the event and created distr. busses named aa , bb , cc ( still red because there is no sender )
Then in the macro I created 3 constantss and no matter what bus I uses , they stayed red .
UNless I stayed on the same level , then it works but not outside the macro
0 -
distribution sends to current level, macros within that level, and sub macros of those...
You cannot sent from a Distribution Bus to some parent structure above it in the hierarchy. It is clearly defined. Distribution is same level, or down the layers.
If you want to send from somewhere deeper in the structure to a target at a higher/outer layer, you need to set up a Reception Bus at the target, and send to that from the source deeper in the structure.
It is important that Distribution Busses work this way, or all the neat mechanisms allowing us to do things like override/gate clocks etc. would break.
0 -
O.K ; got it thanks
0 -
OK , I 've got the hanng of reception busses sending data from deeper into the structure to top macro level , it's indeed a time saver .
BUt what I can't manage to do is send from one macro to the other in the same level.
0 -
BUt what I can't manage to do is send from one macro to the other in the same level.
The Distribution Bus is not in the same level or higher than the target (the parent macros are)... what you are trying to do is go up a level, across to a different macro and then back down a level. Won't work...
The only way this is possible is with non-solid macros, but that's only because the compiler doesn't see them as macros.
0 -
I n the above screenshot the distribution busses worked fine (second screenshot showed distr. to higher level macro's
It's the reception (outlet red ) and busses that are greyed out .
My point was that sending data from one macro to another in the same level is not possible
Unless doing this
0 -
I'm not seeing the issue here. Nothing in these pic go against the definition.
Distribution goes down the hierarchy, or to same layer, Recaption goes up or to same layer.
What your pic shows is two macros on the same layer, but anything inside them is not on that layer it is on a deeper layer, and they are separate macros, so those deeper layers cannot be implicitly 'connected' that would be crazy, and impossible to manage.
I really don't see the problem here, the hierarchical layer thing is very simple. Maybe you are expecting there to be more to it, so finding complexity where none exists? I know I do that!
The reason they are called 'scoped' busses is because their scope is carefully defined in a way that makes them a useful programming device. That would break down if there were implicit connections between the internals of different macros.
Maybe an easier way to think about it is that a Distribution Bus can only send to things visible on the same edit pane that it occupies, or inside macros that are also visible in that edit pane, or children of those macros.
There are no Distribution Busses visible in this pic. If you click down into that left macro where you can see the distribution bus, the macro on the right in the pic will be OUT OF SCOPE, it will be at a higher level, so cannot receive from that bus. Anything inside the macro on the right is completely separate from anything inside the macro on the left, they are in two completely different scopes. This is crucially important, otherwise important stuff would just break.
Here's a toy example of a possible use case:
in the top pane there are two oscillators, each has a clock gate. For the audio clock, it's setup so that if type=1, then the sawtooth gets clock, but the pulse doesn't, and if type=0, the pulse gets clock and the sawtooth doesn't. So whichever is not active uses no cpu. This is great, and very very useful!
but wait, the sawtooth and pulse are both macros on the same level as each other, and if you look inside the sawtooth (lower pane) you will see that the SR input connects to a Distribution bus which overrides the SR clock and sends it to everything in the scope of the macro. Exactly the same mechanism exists in the pulse macro...
If a distribution from inside one macro could send to receivers in another macro (both macros at the same level), then there would be a clash here, both macros each have a distribution bus called SR. So that wouldn't work, and it would break the main purpose of having these busses. That's why controlling Scope is so important, and why it's has been done in this way. It allows you to have some global event streams that are used by many different parts of a system, but wherever you need to, you can override them locally within the scope of some individual macro (and its sub-macros)
Just remember that a macro (with solid checked in it's properties) defines a scope that includes any/all sub macros, and that a distribution bus inside that macro can only talk to things within that scope.
0 -
Lol , now you've got me even more confused with that picture
Inside the sawtooth macro there is a distribution (fiber) bus called SR ( yellow rectangle )sending it deeper into the structure , but one level higher(top pane ) it's picked up by the gate macro ?
Unless I am totally misinterpretting the image
0 -
Unless I am totally misinterpretting the image
heh, yes, a misinterpretation, but understandable.
The point is that in this case, the (Bundle) Distribution BUS 'SR' exists outside at some higher level, but then inside the Sawtooth macro, it is 'overridden' so basically, the external version cannot be used directly within the scope of that macro and it's children, only the new version. Those SR pickups in the top pane at the Gate macro inputs are reading a different 'SR'!
That's the point, the macros an modules inside the Sawtooth don't care, they just listen to 'SR', but thanks to the scope mechanism, us builders can control that and use it. It just makes core a bit more flexible and a bit more expressive.
One other little detail that is important is:
This pickup is different, it is preceded by two dots/periods. That means "listen to the 'SR' BUS from the parent, not the one at this level. That is really useful to prevent loops. In this case, it is being used as a default, so if there is no external connection to the SR input, it automatically uses SR from the parent.
You probably know about this, but in case anyone is lurking, input defaults are another interesting useful core mechanism generally. Here's another example (unrelated to busses):
so here, if there is no external connection to the R input, it gets a copy of the L input. Nice :)
0
Categories
- All Categories
- 18 Welcome
- 1.7K Hangout
- 68 NI News
- 898 Tech Talks
- 4.6K Native Access
- 17.8K Komplete
- 2.2K Komplete General
- 4.8K Komplete Kontrol
- 6.3K Kontakt
- 1.1K Reaktor
- 407 Battery 4
- 923 Guitar Rig & FX
- 467 Massive X & Synths
- 1.5K Other Software & Hardware
- 6.4K Maschine
- 8.2K Traktor
- 8.2K Traktor Software & Hardware
- Check out everything you can do
- Create an account
- See member benefits
- Answer questions
- Ask the community
- See product news
- Connect with creators