Subject: Re: [linux-audio-dev] Re: LADSPA GUI
From: David Olofson (david_AT_gardena.net)
Date: la maalis 11 2000 - 18:20:53 EST
On Fri, 10 Mar 2000, monty wrote:
> *** it appears to me this distinction
> hinges on whether we want plugins to
> generate controll signals which drive
> other plugins ****
Unless a separate API or completely non-standard methods are used
for plugin/GUI interaction, this distinction lies only in the
usefullness of the data that is passed between a plugin and it's GUI.
As this interaction normally *has* to be thread safe and should
support connections between different processes, a suitable API will
be needed anyway. If this API is in fact the same API that is used
for interconnecting plugins, I don't see where the large/fine grain
distinction is.
A useful interface is very much a matter of cutting where there is
least complexity in the interaction. This is how you get abstraction
and flexibility for free. Leaving the UI communication part out of
the API is, as I see it, doing it wrong, as it is a problem that
*does* have to be solved anyway, and solving that the right way while
at it, eliminates quite a few problems.
> my impression is that the large
> granularity case is a lot more
> interesting.
While others would say that it's more or less useless. :-)
I'm interested in both kind of systems, and being both a user and
programmer with electronics design experience, I can't really see a
logical distinction between them.
Most plugins have internal signals that would be *very* useful to
control other plugins with, but due to the restrictions of VST and
DirectX hosts and plugins, this cannot be done. Instead, other
plugins or clumsy work-arounds are needed to get the job done.
> lower level dsp
> code is better shared as a function
> library than kludged out of plugins.
Where does this leave the end user?
> if you want a modular synth or a
> reverberation model, build it and
> feed it's output into a network of
> other plugins.
Again, how does end users get *any* benefit from a new
plugin/client/server API is this is *still* how it must be done? I
don't see the point in all this if we get no technical advantage.
There is already a heap of too specialized plugin APIs.
> i would want my
> audio workstation to emulate an entire
> studio rather than a particular
> dsp algorithm.
I think this is only accepting and emulating the limitations of the
old way of doing things. It works well, but some other advantage
with native processing systems than price/performance would be nice.
> someone is going to tell me that
> they want to implement a system
> which supports both granularities.
> this strikes me as a mistake.
> yes it's probably possible to make
> a totally generic API which will
> let you interconnect anything and
> everything just like your old
> modular synth. however, what host
> is ever going to actually want to
> support a true mixture ?
A host doesn't need to bother if there is any sense in the way the
plugin API is designed. A GUI element or panel should be a soft RT
plugin. Mosts systems use something completely different with it's own
separate API for user interfaces. No wonder a system supporting both
"granularities" can't be built around that kind of designs...
> aiming
> for something totally generic is
> a noble cause but such projects
> collapse under their own weight
> or never actually get used because
> they have absurd learning curves
> etc.
The UN*X style pipes and IPC APIs seem to survive... They are doing
what I believe a plugin API should do, but in a far too generic
fashion, and too low level for most multimedia, signal processing and
controll applications.
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST