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: Fri Nov 17 2000 - 19:47:52 EET
>What is missing in LADSPA is besides network transparency and IPC the ability
>to talk to components in a more complex way than streaming data around. The
>HDR issue illustrates: you want to abstract the HDR engine from the
>application that is using it. So an HDR engine should be a component like an
>equalizer or a freeverb effect.
The problem is that this kind of "abstraction" doesn't get close to
the real complexity of interlocking:
* an audio interface with hardware monitoring
* an audio thread
* a disk thread
* a rich and powerful GUI that provides lots of feedback
on state, and multiple ways to do things
* Model-View-Controller design issues
So no, I don't want to abstract the HDR engine from the application
that is using it. Not for one minute. You might be able to build a
simplistic kind of HDR system this way, but not something that can be
used as a professional recording system because there will be too much
decoupling of the various parts of the system. Or let me put it
another way. While building ardour, i had to continually refine the
set of interfaces i wanted my audio h/w interface class to present. To
build Ardour "into" aRts, for example, aRts would have to be extended
to provide things like:
* sample clock sync status
* toggling h/w monitoring
* changing the digital sample clock source
* getting meter values even though nothing is being played
or recorded
No "vanilla" audio app needs to be messing with this stuff, but a
studio-ready HDR system does. I doubt whether most people's current
"abstractions" of audio i/o include any of these functions.
The only thing I want to abstract is the idea of an audio interface
that wakes up every so often, calls some function for every plugin its
connected to, and goes back to sleep again.
I would be interested in Stefan's thoughts on the comparison of MCOP
and libsigc++.
--p
This archive was generated by hypermail 2b28 : Fri Nov 17 2000 - 20:32:51 EET