bus extract/create limitations

[tester]

Quick question: what are the limitations of bus create/extract primitives?
I see that I can send through its node a multi-signal, that was combined in another bus...
Are there any known issues with these primitives?

[trogluddite]

There are a few kinds of data which cannot be sent via busses - I've never seen an exhaustive list, but I think that most GUI (yellow) data is not possible, and other "bulk items" such as bitmaps and mem's. So test first if you aim to use anything unusual - but strings, floats, integers and all kind of streamsare certainly no problem for it.
Unlike wireless, it is only the naming that is used to tell the"channels" apart - SM's automatic data-type conversion will be used if the two ends have matching names but different data types (as long as such conversion makes sense). You can't have two "channels" with the same name (but different data types) - only the first occurrence of each name will be work properly. However, so long as the names are unique, it is fine to have channels carrying different types of data.
Wireless connectors will also work with busses. I find this handy for organising wireless parameters - for example, it's easier to find the transmitter for a parameter called "Width" if I know it came in on a wireless bus called "Bitmap Data".
By altering the string that names the channels dynamically, bus routing can be switched very flexibly (see the "Mod Matrix" modules in the toolbox for an example). You can use any of SM's string modules to make the "channels" string - enabling the automatic generation of lists of "channel" names. However, I have found that using too many buses does slow down preset changes etc. - I guess because the routing requires so much text parsing etc.

[tester]

Thanks for explanation on that. How many buses are beginning to be too much? Does the slow-down applies only to busses that participate in preset transmission, or to other busses (like the ones that operate on audio signals only and work as a fixed matrix) too?

[trogluddite]

Far as I can tell, the "slowdown" only happens when the connections are made/broken.
So for "fixed" connections, it will only be at load time - but if used for e.g. mod matrix it will also affect preset changes.
Number is hard to say, it is a very subjective thing. Some people get frustrated if loading takes more than a second - but I am from the times of rewinding cassette tapes, and presets were loaded "manually" from paper charts!!; so some extra waiting is fine for me if it allows better sound/functions.
It also depends on overall "complexity" of connections, not just quantity - though I think this applies mostly to streams, as green parts work by always "tracing" the route of triggers, whereas the very essence of the code being run must change when streams are re-routed. To be fair, all parts that allow dynamic routing of streams (e.g. selector, multiplexer etc.) exhibit this...
When routing is changed SM "re-compiles" the entire schematic to analyse which modules are unused. This allows good CPU saving even when many "optional" parts/functions are included. When there are many connection possibilities, it will take more analysis to correctly determine the "dormant" modules. Often it is the spike in CPU load at this time which is more of a problem than any time delay. I have made a few plugins which are usually low CPU, but cause audio "glitches" at preset change even with big audio buffer sizes (ReDraws can also be a big cause of this).

[tester]

Okay, thanks for info on that. After I added a section with "harmonics" to my project (which means - all sound modules are duplicated, because way of adding modulation is sitchable, and sound frequency is applied via custom ratio) - I noticed that there are some dropouts when switching parameters, so maybe this is what you mention.

[trogluddite]

I noticed that there are some dropouts when switching parameters, so maybe this is what you mention

Yes, that is very likely. The "re-compile" will also make all code/assembly return to stage(0), so can sometimes cause reset of envelopes/oscillator phase/MIDI notes etc - and of course, stream processing will stop for a short time while the routing gets analysed.

[tester]

This leads me to another direction of thinking too. Busses versus FloatArrays. Theoretically arrays could be used in similar way like busses, plus they can serve as data buffers I guess (for switching between destinations when working with multiple knobs and switches at once). Probably tomorrow I will start checking on that. Do you have any experience on that?

[trogluddite]

Posted some thoughts on other thread - seemed more "on-topic" to follow on from the schematic you posted.

[tester]

Bus size. How many I/O elements bus can handle being stable? Like 100 or 1000 or 5000 elements? And related - what is the lenght limitation for string primitive? Or I guess bus connection can be described via text primitive too?

Explanation. Instead of making over 2000 wireless outs and 2000 wireless ins, I think in my "little" project - I could double a set of multiplexers (text primitive can serve as a buffers as I found) from c.a. 130 to 260, make few very large bus bridges for these multiplexers, and then extract from these large buses only portions of data via small buses (somehow similar to arranging folders in windows). It's easier here to make wired connections than describing wireless connectors. Trog - in your view could it work?

[trogluddite]

Intriguing question. I have no idea what (if any) limits there are, as I have never pushed things that far.
My guess would be that memory is the only limitation. All links in SM are nothing more than references to memory locations where the data is kept (equivalent to a float variable in code). Whether they are wireless, bussed etc. is little more than a choice of how we would like the data presented graphically - and I see no reason that bus/wireless names should be any more greedy than any other text annotation that we put in our schematics.

In a way, links (of any sort) don't really exist inside SM - once securely "hooked up", all that happens is that output connectors dump their data in a certain memory location, and inputs fetch that data whenever they need it. Apart from triggers, there isn't any coded "mechanism" involved in passing the data. The links we see inside the workspace are not "conduits" or "pipes" along which things truly flow - they are just a graphical representation of which connectors reference the same "variable".

AFAIK, the only penalty for using wireless or busses is a tiny bit of text parsing that happens at the moment of making a connection - no different really than what must happen when we use the mouse to drop a link onto a connector. In fact there is an interesting contrast between busses and selectors/multiplexers in this respect...
Once a bus is connected, that's it, the ends are joined and it is "invisible" until you next make a change. In contrast, with multiplexers and selectors, a green trigger at any input, causes the index to be polled - sometimes resulting in quite a flurry of triggers while SM goes about "double-checking" the routing.
So busses should in theory handle "green" data more economically than a selector/multiplexer routing matrix - the downside is that busses have a lot more to do when changing presets etc. (parsing the connector names).

Re; "Folders".
AFAIK, it is still not possible to "nest" busses - that is, you can't use a "sub-bus" as an input to a Bus Create.
However, one thing you can do is to "sum" the outputs of several Bus Creates. If you do this, the combined bus will contain all of the unique "links" from all the "added" buses. If any buses have links of the same name, the combined bus will have one link of that name, and the various inputs will be summed...

Bus Combining.png (52.77 KiB) Viewed 546 times

[tester]

Thanks, I missed somewhere that part with combining buses that way In other words doing so should work well.

Regarding buses vs wireless I noticed, that sometimes wireless can get inactive for some unknown reason (interaction with other wireless with the same name) and the bad part is, that you don't know it until you check it. On the other hand automatic conversion on buses sometimes can be confusing - in situations when you manipulate bus descriptor while bus is connected both sides - that why I asked, because buses are refreshed according to list.

So regarding multiplexers and selectors... Having c.a. 130 individual parameters to change per one click - I will have 130 selectors and 130 multiplexers, plus another 130 multiplexers if using buses and not wireless. Total 400 triggers (but 130 are discrete). But all these are on greens and during switch - green values are constant (not changing). So the only spike could affect CPU usage on audio section.

I guess it shouldn't be a big problem but we see in following days.

[tester]

Work area (height of schematic) in SM allows to display c.a. 120 bus nodes, so this is the limitation. So good thing with mixing buses. Bus approach instead of wireless should be also better, because multiplexers can be switched one set after another. First - preset is loaded to buffers (greens), then circular auto-switcher can send buffered values to audio sections one after another. So there will be no situation in which kilograms of oscillators are getting values at the same time; only 1/16th per circular cycle.