Re: [Traverso-devel] Routing: SubGroups

[Remon Sijrier]

Hi Plutek,

Thanks for jumping in!

> one thing that jumps out at me is this statement, on page 8: "In theory the
>  MasterOut bus is nothing but a subgroup where all signals pass through
>  before going to the hardware."

I think Nicola meant that this subgroup has no other function then that every 
track/subgroup that 'send' it's processed data to Master Out is 'send' to the 
hardware playback that was configured.

> 
> does this imply that you are not allowing connection to external processes,
>  except from MasterOut? there are lots of scenarios in which one might want
>  to send signals from subs or tracks to other hardware besides the main
>  monitors, or to other software for processing. then, of course, we should
>  also be able to connect arbitrary input points to output from other
>  software as well, so that we can form processing loops which are external
>  to traverso.

You mean using jack ? That's partially what this change is all about. Each 
Track will be able to send to whatever 'playback' (also called output) Bus the 
'AudioDevice' presents. AudioDevice is Traverso's abstraction for the 
different audio drivers we support. In case of using the JackDriver, the user 
will be able to create 'virtual ports (grouped in Buses)' which can be 
selected as output/input buses in Track/SubGroup's .
The user then still has to connect the ports in e.g. qjackctl

> 
> i guess, in terms of external DSP, i'm getting into things which are
>  usually handled by inserts and sends, which may be beyond what you're
>  currently implementing. however, for live monitoring, the ability to send
>  Sub or Track outputs to arbitrary hardware could be quite useful.

I'm aware of that, it would mean (from my understanding of sends/inserts) that 
a Track/SubGroup can send it's data to multiple 'receivers', correct?

Something for a future release most likely, unless you think it's critical 
from a design pov, so we don't have to redo the work we're planning to do now 
:)
In fact, if this is what you meant, then it shouldn't be too hard to 
implement. Something that worries me though is how to deal with latency, so 
eventually we have to rewrite the processing control in Traverso but who 
cares...

Greetings, Remon