Using BUS

Dest/Src are the bus number to use....

but let's take a step back...

I think it's easier to think of the BUS object as 2 modules combined into one.

this is cool, but can create a bit of a misunderstanding about buses

lets imagine instead, 2 modules BusIN, which has 8 inputs, and NO outputs BusOUT , which has 8 output, and NO inputs.

this would work like

BusIN -> [ internal bus, with 8 channels ] -> BusOUT

so... if you send to BusIN::In3, it comes out of BusOut::OUT3

ok, cool... but this limits us to 8 data channels.

so instead we extend this so there are 64 internal busses, so the BusIn/Out modules can now refer to one of these using Dest (BusIn), and Src (BusOut)

( a bus is just like a mixers 'sub channel', or a daws 'send' except its not a stereo pair, its got 8 channels)

BusIN (Dest = 24) -> [ internal bus # 24, with 8 channels ] -> (Src = 24) BusOUT BusIN (Dest = 11) -> [ internal bus # 11, with 8 channels ] -> (Src = 11) BusOUT

this is whats going on with the SSP except the SSP has one BUS object which is combines BusIn and BusOut into one object. BUS (Dest = 24) -> [ internal bus # 24, with 8 channels ] -> (Src = 24) BUS (a different BUS object)

what is important to realise here (and where confusion might arise) is internally for a particular BUS object there is not a direct link between its input and outputs - its like having 2 separate modules in one.

---

what's this used for?

a) patch design #1 - bigger patches

we can only patch between objects on the same network page, so we can us a BUS to send audio/cv from a module on page 1 to page 16

b) patch design #2 - organisation

we might want to group the functionality of a patch 'logically' e.g, put a number of modules together in a page (block of 8) ( e.g. page 1) for an oscillator voice. and then put our FX/ master output on page 15/16.

theres a few benefits to this, partly patch readability, but also allowing you too quick/easily rearrange things. (it'd be awesome if one day, we could copy pages within a patch, or between patches!)

c) patch design #3 - mixing

so if we design using (b) , we might have a couple of different voices (say page #1 and page #2) which go to a common fx change (page #16) via a BUS (e.g. bus #1) , and they are mixing into the same bus #1

but we could now easily change this so that page 2 uses a different fx change. just create the new fx change on page #15, with a new bus, src'd from bus #2, and switch the voice on page #2 to use bus#2

d) overcome limitations for linking objects. a single module connected to two objects, will connect to same inputs on each. this is a bit tricky to explain... as its not that common....

imagine a MIDI connected to two LFO modules. on one LFO you want to connect MIDI:GATE to LFO1:AMP, on the other what you want is MIDI::GATE-> ENV:GATE-> ENV:OUT->LFO2:AMP

unfortunately this wont work. what will happen is MIDI:GATE will go to both LFO:AMP, since you cannot distinguish between the two lfos.

but we can use BUS to get around this

e.g. MIDI:gate -> BUS:in1 BUS:out1 -> LFO(1) :amp

MIDI:gate -> BUS:in2 BUS:out2 -> ENV:gate ENV:out -> LFO(2):amp

the reason this works, is because midi is now sending to two different inputs. (bus:in1 and bus:in2)