Re: my take on the "virtual studio" (monolith vs plugins) ... was Re: [linux-audio-dev] ardour, LADSPA, a marriage

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: my take on the "virtual studio" (monolith vs plugins) ... was Re: [linux-audio-dev] ardour, LADSPA, a marriage
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Thu Nov 23 2000 - 16:57:08 EET


>> ignoring libsigc++ for the time being (because its not part of LADSPA
>> at all): the scheduling in my proposed system is actually extremely
>> simple:
>>
>> ALSA poll(2) support:
>> * wakes up a thread very fragment
>> * this thread handles the low-level interaction with the audio h/w
>> and calls the "run" method for the patchbay/router/host.
>>
>> The patchbay/router/router simply executes the "run" method
>> for every plugin connected to every input port, then
>> executes the "run" method for every plugin connected to
>> every output port.
>
>Well, this sounds simple enough, and seems to operate on unmanipulated
>data.

Actually, no. The router/patchbay provides two 2 lowlevel operations:

          read_from_channel (size_t channel, Sample *buf, size_t cnt);
          write_to_channel (size_t channel, Sample *buf, size_t cnt);

which do the necessary conversion to/from Sample. At this time
"Sample" is a float. If we ever get real 32 bit sample h/w, it will
become a double.

> On a very low level, too. It would even be possible, if you put
>that thing in a library to connect aRts to it as client.

for me, that circumvents the whole model of a patchbay. in the
physical world, the patchbay sits between the "real" ins/outs and
everything else - *nothing* else except cabling sits between them. i
think it should be the same in this "virtual"/digital realm as well.

that said, the question is: what *are* the "real ins/outs" ?

in a studio, typically that means the ins/outs on the mixer.
in a computer, i would tend to consider them the ins/outs on the audio
interface.

the problem is that i see both points of view as very legitimate. you
probably want most other "apps"/clients to connect to the mixer, not
the raw audio interface model. OTOH, there is no reason i can see for
preventing that.

>It's not my view of a virtual studio, though, where you would allow
>having a mixer as plugin, which would mean that apps should connect
>to the mixer, and the mixer mixes and connects its output to an effect,
>and the effect,... and so on.
>
>Of course, you *can* do all this by going repeatedly through the patchbay,
>but unless your patchbay then supports float i/o, and not operates on raw
>data, it will be very inefficient.

As noted above, it does operate on float i/o. And the model I have
for the setup you are describing is:

    client1 client2 client3 client4 client5
         \ | / | |
          \ | / | |
                                                            |
              mixer plugin chain |
                \ | |
                 \ / /
                  \ / /
                  patchbay/router -----------------+
                      |
                   audio h/w

this model allows some "clients" (plugins in the low-latency worldview
i have) to connect directly to the patchbay, and others to connect to
other clients that do various processing for them. but there is no
heirarchy here: the mixer, plugin chains etc. have no clear temporaral
or priviledge precedence over anything else.

>My feeling is also, that it standarizes too little to make the audio apps
>really interoperate in a user-friendly way. They don't really talk to each
>other the way you describe it. They don't offer services to each other, like
>a harddisc-recording-services. It's not an API for component oriented
>programming, but one for using huge monolithic blocks together.

I'll comment more on this in my response to your other message. The
gist of my feeling about this is:

     * for non-low-latency work, the MCOP approach seems very flexible
         and appropriate

     * for low-latency "dedicated h/w" work, component oriented
         programming needs to be subsumed to a plugin model

I claim in my defense all the commercial implementations of DAW's. Not
that a million flies proves that eating shit is a good thing, but
there's also no smoke without fire :) I hope those two english
language aphorisms have some meaning to the non-native english
readers/writers here.

A final note: the ALSA library is also trying to do some of this. I'm
not sure what to make of all this.

--p
         


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Nov 23 2000 - 17:43:53 EET