Using Busses Tutorial

philter5 · 8 Nov 2009

good job! 😉

faizzer · 8 Nov 2009

It's well explained, and easy to understand.

thanks 😀

Shalako · 11 Nov 2009

Nice, I never would have considered using a bus as I didn't reall know what to do with them until now. My projects seem to get quite large so this is going to be very useful.

trogluddite · 11 Nov 2009

Thanks for the nice comments 😀 always nice to be appreciated.

AN APPEAL... More people should get involved with the Wiki. When you sit down and try to explain something to someone else, it really makes it clear in your own mind - already I have taken my own advice for tidying up some projects that I stopped because they got out of hand. Helping with the Wiki will help you too. I noticed that new forum users ask many of the same kind of questions (same as me when I started with SM) - but there is a lot of simple stuff that is not there in the documentation. It is too much work for a few people to do all of this - especially too much for the developers (we want them to have time for adding all the lovely features we want).

EDIT: (Thanks to infuzion for his pointers - see next post) So, if you see somebody ask something on the forum and you know the answer - don't just tell them - follow the thread through until there's a consensus about the solution. Then see that it's added to the Wiki.

Thanks Again The Luddite

infuzion · 12 Nov 2009

Thanks for making a new tutorial! It is a well-formed how-to.

A few suggestions: 1) Use a shorter URL for the WiKi, with out a repeat for the last word. For some reason it seems to default to repeating the last phrase. Not a big deal when the page-name is only one word, but some URLs can get out of hand. I would recommend the following URL:

http://www.synthmaker.co.uk/dokuwiki/doku.php?id=tutorials:bus ...which would end up being a page for all things about busses. If you want only the topic about "Decluttering with Busses" to have its own page, then make the URL= http://www.synthmaker.co.uk/dokuwiki/doku.php?id=tutorials:decluttering_with_busses

2) Make a reference link to your final URL in the bus primitive reference, preferably using the style guide.

3) The bus system has an issue in 1.1.3, most/all previous versions, & likely onward where the Bus Extract does not properly change the link types. This can cause increased CPU%, confusion, & an editor crash if you do not somehow force they connector types of the Bus Extracts' outs. For example, using your example, if you connect that Bus Extract directly to an audio in connector, that pin on the Bus Extract will change to that audio type, not Float. So you have to force the Bus Extract's connector type by either putting the Bus Extract inside a module & right-click the Outs' connector types to manually select Float, or put a dummy module between that you filled with float In/Outs.

4) Honestly, I recommend against using the Bus system except for the few times if you need to run-time re-route a group of connectors with another group of connectors (eg Routing Matrix). Due the bug/behavior listed above Buses can actually cause more frustration then they solve, use up development time since you have to jump in & out of multiple modules when you need check something, quick test change a range, etc, & they can increase file size which is a SM no-no since SM is more sensitive to large OSM sizes. For most other programming languages you do want to separate layout, interface & logic from each other, but in SM, due to it not being text-based (& not able to search, bookmark, auto-complete etc), you want to keep them together for simplicity & reduction's sake. IMHO 🙂

trogluddite wrote: More people should get involved with the Wiki... I noticed that new forum users ask many of the same kind of questions... if you see somebody ask something on the forum and you know the answer - don't just tell them - ADD IT TO THE WIKI -even if it's just a link.

I would think it is better to have the answer to be answered in the forum first, since it could be the wrong answer or the right answer in a misunderstood format. IMHO the question-poster should post the final correct answer in the WiKi when (s)he fully understands the answer, & write it at the technical level (s)he is at. This will help prevent the WiKi from being clogged with a bunch of wrong answers. I always envisioned the WiKi to be the final resting place for matured info.

trogluddite · 12 Nov 2009

@infuzion

Thanks for the pointers - like I said, I'm a complete noob when it comes to Wiki's - your hints will be very useful. I'll try to update the tutorial on the next few days to incorporate your ideas.

Point taken about the data type problem - I tend to make data types explicit wherever I can as a matter of course, so I forgot I might need to warn others of this issue.

Think I maybe got a bit too enthusiatic about the Wiki - I see what you mean about making sure the data is accurate, but I feel that at the moment far too little is being posted there. I'll add a few notes about Wiki 'etiquette' on my other posts on the subject though, as I understand your concerns about it getting swamped with unverified info.

Thanks again The Luddite

infuzion · 12 Nov 2009

Please don't get me wrong; the bus WiKi you wrote Luddite is very good! Unfortunately due to the unique connector behavior the Bus Extract needs an extra step.

trogluddite · 13 Nov 2009

No offence taken at all - I was very glad of your input, it was just the kind of help I needed as a Wiki noob 🙂 . I hope to update the tutorial this weekend - my SM machine is not on the internet (Antivirus etc. makes big trouble for my soundcard drivers). As long as criticism is constructive it is always a good thing.

The Luddite

McBarGig · 3 Mar 2010

Great tutorial...This is probably not the place to ask, but what type of impact does using buses have on CPU Consumption if any?

Once again thanks for the tutorial

trogluddite · 3 Mar 2010

McBarGig wrote: what type of impact does using buses have on CPU Consumption if any?

Never tested it in very much detail to be honest, but there doesn't seem to be any penalty once the connections are in place. However,I have noticed is that the creation of the connections can take a fair bit of CPU when a schematic compiles - i.e. when loading, or if you change the routing - I suppose that's because of all the matching of string names needed to establish what signals go where. For this reason, I tend only to use busses for tidying up schematics. There's nothing to stop you from using busses in place of selectors and multiplexers by changing the string names while the audio is running (like the matrix modules do) - but if you change too much at once, the re-routing can lead to some nasty pops and farts as the routing is re-calculated - especially if the busses are carrying streams.

P.S. Glad to see the tutorial is useful. Apologies to all for not getting around to tidying and amending the Wiki page, I kind of forgot it was there. There are defiinitely a few other hints and warnings that could do with putting in.

McBarGig · 3 Mar 2010

So in terms of "normal" coding, a bus would be what, like a collection with nodes? Still either way its not like you are going to have thousands of collection items right? Even if yo had like 100 that still only amounts to 4 bytes overhead per node...plus its contents...Cool..

trogluddite · 4 Mar 2010

Simpler than that possibly. Malc would know for sure, but I would imagine that routing a bus would be a bit like typing the name into a wireless connector - it would generate a trigger telling the compiler to find the other end of the connection, rather than having code scanning the string constantly. Once the re-routing was done, I would expect the overhead to be tiny, cos the pointer to the other end of the connection would just stay fixed until a change in the string made another trigger. That would make the CPU overhead for switching quite high, but once the connection is there, the overhead shouldn't be much more than for a wireless connector (i.e.next to nothing).

trogluddite · 4 Mar 2010

Just been testing my theories using the CPU analyser etc. Looks like I'm pretty much right about the CPU usage - the buss system uses slightly less than the selector once everything is routed . If I made the routing change at 25Hz however, the triggers to the bus extract make the CPU usage go way up (you have to use wndows CPU monitor to see this - SMs meter doesn't measure trigger related CPU). So as long as you don't need to modulate the switching at high speed, the bus extract is a bit more efficient than a selector.- and more so compared to a multiplexer.

McBarGig · 4 Mar 2010

Interesting...