Subject: Re: Re[2]: [alsa-devel] Re: [linux-audio-dev] laaga, round 2
From: dgm4+@pitt.edu
Date: Mon May 14 2001 - 18:05:27 EEST
At the moment, I don't think we're actually discussing interfaces yet. The
buss vs. patchbay discussion involves the actually implementation of
routing in the server. Interfaces would be left up to the individual
applications that use the server. At least, that's my understanding.
(Correct?) I'm not familiar with the CFX12, but as per my understanding,
when people talk about a "four buss mixer", they are talking about the mix
busses. That it, you have four busses at mixdown that you can route audio
to. However, most boards have more actual busses than that. Your aux
sends are busses too, so if you have 4 aux sends and four mix busses, then
that's 8 busses. The you have the stereo buss, which has two channels, so
that brings your total to ten. At least, that's my understanding.
-dgm
--On Monday, May 14, 2001 10:17 AM -0400 Rick Burnett
<destinytech_AT_spacey.net> wrote:
> I guess I am a bit confused about the discussion of bus models.
> Someone please fill me in :) I own a Mackie CFX12 which has only 4
> buses. Now, if I am not mistaken, the buses are what I can assign
> channels of the mixer to, and then the buses can be assigned to the
> master output. Now what I do not understand is how this would not be
> complimented with a 'patchbay' type approach. For instance, each
> channel has inserts pre or post, and all items can be sent to the two
> effects channels. However, if I wanted to string a bunch of effects
> units together, I would have to do it seperately from the mixer.
>
> Now, I would be in favor of an interface like quasimodo, where you
> graphically attach all components together with virtual patch cables.
> What I do not like is a 'patch-bay' that has to be in-between, there
> is no reason for it. It just adds confusion by adding another
> component, that in a computer is really doing nothing. Likewise, I
> imagine, that if you keep the mixing part and the plugin part
> seperate, things are real easy then.
>
> If I have misunderstood anything, please let me know. I am trying to
> understand the approach so that I may add to help to the discussion in
> constructive ways :)
>
> Rick
>
> Sunday, May 13, 2001, you wrote:
>
>>> For what it's worth. I know Paul doesn't seem to understand how much
>>> difficulty his bus model is going to cause the user, so I don't expect
>>> much movement here unless Almighty-God-On-High intervenes with a
>>> miracle.
>
> TP> While the buss model may or may not be the best for an all
> encompassing TP> server, it is the most accurate model for representing
> the functionality TP> of a physical mixer. AES/ardour is a
> mixer/recorder/editor, so it makes TP> sense that it would evolve to this
> form to provide mixer functionality. TP> For comparison to physical
> mixers, take a simple mackie 1604 vlz. It TP> has 26 inputs, 25 outputs,
> 18 inserts, and 16 busses. More advanced TP> mixers have even more
> busses. A user who is familiar with the buss TP> architecture within a
> traditional mixer will probably find this model TP> quite easy to
> understand and a pleasure to use. You favor a patchbay TP> model.
> Interestingly, the patchbay configuration that many users find TP> to be
> the most useful is the half normal configuration which adds TP> limited
> buss functionality to the patchbay concept. One could design a TP> gui
> that allows some busses to look like a patchbay, a buss with only TP> one
> input. Busses are very generic and can be used in many ways, TP>
> including all of the ways that a patchbay can be used. Patchbays can TP>
> not provide all of the functionality of busses. AES has 32 busses, and
> TP> the connection to them can be made to look like anything; a channel
> TP> strip, an aux send, a patchbay, or whatever (paul, maybe you should
> bump TP> this back up to 64 busses). The fact that paul realized that
> the buss TP> architecture of the mixer can be opened up to be accessible
> to other TP> apps should not be seen as a problem.
>
> TP> Tom
>
>
This archive was generated by hypermail 2b28 : Mon May 14 2001 - 18:31:12 EEST