Re: [Traverso-devel] Routing concept

[Remon Sijrier]

Hello Nicola,

Thanks for the explanation!

I think I get the idea, we have talked about it before, however then it was 
more about subgrouping, right?
IIRC, you called a subgroup also a Bus, which was similar to the AUX Bus 
concept, however you wrote that a SubGroup Bus could have AudioClip just like 
Track's.

I need to re-read the emails about that subject to refresh my memory, I'll try 
to do so in the weekend.
From a coding point of view, it would be nice if things are very clear for me 
what Tracks and (AUX/Grouped) Buses share, how the routing code should look 
like, and if for example an AudioClip, Plugin or even Song 'share' or could 
benefit from some of the routing concepts.
(If they all 'share' the same routing concepts _and_ code or parts of the 
code, they could inherit from a "Routable" class for example...)
Also, things not 'possible' in hardware, could be done easily in software, 
like adding AudioClips to an AUX Bus ;-)
Just something to think about hehe.


Greetings,

Remon

> I'll try to explain my ideas for a routing concept (although it's probably
> too late, after midnight...). Also have a look at the attached
> illustrations if you can't follow my explanations.
>
> Let's start with the patch bay shown in the first illustration
> (print1.pdf). This is my suggestion for a dialog which lets the user manage
> the routing setup (heavily inspired by the connection dialog of qjackctl).
> It's devided into three parts, the input routing (left), the internal
> routing (middle) and the output routing (right). The input routing section
> assigns hardware channels to tracks for recording. Accordingly, the output
> routing section assigns track / main outputs to hardware playback channels.
> The central part defines the internal signal path. Ignoring the AUX busses
> for the moment, this part should also be rather self explaining. If it is
> possible to pipe the output of several tracks to the input of one track,
> the latter acts as a sub group. (Outputs must not be connected to their own
> input in order to prevent feedback loops.) So different types of input
> signal can be connected to a track's input port: audio coming from i) a
> hardware input channel, ii) output ports of several other tracks, and iii)
> the track's own audio clips. All signals should just be mixed together.
>
> Each song should have a variable number of AUX busses. Internally, AUX
> busses are almost normal tracks, as they have an input port, plugins,
> panorama, gain and an output port. Their input port, however, is hard-wired
> as shown in illustration 2 (print2.pdf).
>
> The normal tracks, on the other hand, should be able to send a copy of
> their audio stream, either splitted before (pre) or after (post)
> processing, to the AUX bus. See screenshot1.png for a faked example of a
> song with 1 AUX bus. So for each track it should be possible to determine
> how much of it's audio content is sent to each AUX bus (pre or post
> processing).
>
> AUX busses should have certain restrictions as compared to normal tracks:
>
> - Since their input is hard-wired, it should not be possible to connect
> anything to their input port in the patch bay.
> - It should neither be possible to record into AUX busses.
> - They should not contain audio clips.
>
> I hope you grasp the concept. It's not that difficult actually, but it
> seems pretty difficult to explain.
>
> Finally: Good night!
> Nic