Subject: [linux-audio-dev] Re: The dangers of a do-it-all solution (long)
From: Erik Steffl (esteffl_AT_pbi.net)
Date: Thu May 25 2000 - 19:48:53 EEST
these are all valid points, I just don't understand where we disagree
(and it looks like you (kinda) disagree with me). since I mostly replied
in fairly fragmented way before, let me state what my opinion on this
issue is more coherently:
situation:
we need a way to control plugins and provide feedback from plugins (I
mean other then audio:-).
the plugins are primarily (mostly) audio, but some might have fairly
important visual functionality.
if a feature is not used in particular setup, both user and plugin
author should not be bothered by it (not even have to think about it).
divide & impera! (that's my programming motto too)
solution:
1) the primary (default/preferred) way to control plugins is by
whatever host application decides, plugin is not aware of any gui, it is
only communicating with host using current LADSPA (or something very
close to it). host can create gui based on parameters of plugin, or it
can use other methods to get parameters values (from config file/pipe,
from web, from command line options etc.) and display values from plugin
(write into pipe/file, num lock led, whatever...(think also embedded
systems here))
2) for plugins that want to provide specific gui, xml can (hopefully)
be used. the plugin product (as you call it) would consist of dsp part
and xml gui specification. I guess that the plugin should not be aware
of xml, which would be used by host to provide gui (instead of generic
gui). if author does not want to provide xml, (s)he does not have to
care. I guess it might be possible to have a tool to create generic xml
gui for a plugin (and to be able to customize this generic gui etc...
possibilities are limitless but not really part of LADSPA)
3) optional: for plugins that are _very_ visual, it would be possible
to open create another process (with it's own window etc., or even non
window (svga, ncurses) ui) and use some kind of IPC to communicate with
it. LADSPA basically does not have to care about this at all, even
though recommendations can be made. there are some issues to sort out
(for example - would we always open separate window or provide space
within (one of the) host window(s) (like browser do for example)(ok, so
I overuse '()' a bit:-)).
in this case plugin product would be plugin itself and visual
application, plugin would act as interface between application and the
rest of the audio system (=host). it is up to a decision if there should
be some protocol specified how the plugin should communicate with it's
application (application might be a specific host, plugin would act as a
bridge - but then LADSPA would have to provide another mode of
communication (so far LADSPA only communicates within one process))
4) for now at least ignore the possibility of plugin being able to
have gui in it's own address space (too many problems)
as you correctly state, points 2 - 4 are not really part of LADSPA per
se, but I think they should be part of the overall framework (which can
be called LADSPA or not).
<dreaming>
as I wrote in another post, later on I would hope for
everything-is-plugin framework to emerge (where not only streaming data
but also events would be processed - basically real time component
system, geared towards audio/visual processing). it might evolve around
one of the existing system, like quasimodo or aRts or others (I am not
really familiar with these, so I don't know), or by evolving/building
upon LADSPA or ...
</dreaming>
all in all, I am advocating a set of solutions (framwork?) that would
together be a do-it-all, not one monolithic do-it-all thingy.
erik
Maurizio De Cecco wrote:
>
> I take the following sentence by Erik Steffl as an excuse to discuss
> the matter from a larger point of view; so please, don't interpret the
> rest of this mail as a direct answer, but as a more phylosophical
> discussion.
>
> > well, that's up to decision, it looks like the experience with vst
> > shows that there are plugins whose main functionality requires visual
> > part.
>
> I don't believe that VST should be taken the reference paradigm here;
> on the contrary, i think it would be deadly wrong, and very expensive.
>
> VST is a solution thinked for a well defined system architecture, and
> for a well defined market and application profile; VST is not, and
> don't need/want to be, an open system.
>
> VST provide a complete and integrated solution that works for a small
> set of applications, indented for a couple of application profile
> (MIDI sequencing, post-pro).
>
> VST is a closed system, made to interact only with components of the
> same type, within a closed, predefined context.
>
> Personally, i would like the LADSPA can become a generic building block
> for any kind of applications that use audio, from music applications to
> games, to sound-enriched office application.
>
> I would like the LADSPA engine to be included in all the major Linux
> distribution (including the one i work for :-) as today we distribute
> libc or libgnome or any other essential library.
>
> The Unix tradition is to solve a complex problem by combining simple
> tools, each of them solving a limited and simple aspect of the problem.
>
> This is a good thing to do for a lot of reasons: for example, often
> the technology for the different part of the problem evolve at different
> speed, and we don't want to introduce unwanted contraints between the
> different part of the solution.
>
> This simplify the developement, leaving each person to do what it does
> best.
>
> This make possible that the simple, local solutions are generic and
> orthogonal, and are not limited by assumption deriving from other
> aspects of the problem.
>
> Using a do-it-all VST like approach will make LADSPA absolutely useless
> for most of the audio application, and leave it just for Cubase/Nuendo
> clones; i.e. it would never become a "base Linux technology", and
> it would never get the large diffusion it deserve.
>
> For example, Erik says:
>
> > I don't
> > say that audio and gui has to be meshed together, but both audio and
> > gui should be 'plug-able', otherwise the oscilloscope is useless, if I
> > have to code the gui for it...
>
> The point is that while we know very well how to define a plug-in API
> for a DSP system, and we can reasonably sure that the resulting API is
> generic enough to be used in a vast array of application, we simply
> *do not know* how to define a *generic* plug-able GUI.
>
> Plug-able GUI systems are usually known as "component systems"; COM,
> COM+, OpenDoc, Java Beans, Corba, Bonobo, KParts, are all terms
> related to this kind of problems; no-one have a universal generic
> solution yet, i don't see how we can formulate one here.
>
> Any built-in solution, as reproducing the VST architecture, would
> necessarly reduce the application field of the API, and reduce it
> interest from the generic Linux point of view.
>
> So, i strongly encourage to use the Unix "dividi et impera" (divide
> and conquer) strategy.
>
> Leave LADSPA simple; add the mechanisms needed (if any) to interact
> with a "live" piece of software, like an automation recorder or a UI
> or whatever, but without making assumption on its nature and
> architecture; use standard software engineering methodology and
> principle, like orthogonality and modularity as a principle and blah
> blah blah ...
>
> Consider the UI problem, the automation problem, the communication problem,
> as *different* sub-problems that need different solutions, that can rely on
> the existence of the basic LADSPA library.
>
> Where the domain is well know and developed, we may hope to see a future
> standard API (the LADSPA automation API, for example ?); where it is not,
> we will see a number of competing solutions, like a library for making
> a plug-in API as a bonobo/gtk component, and an XML based interface builder,
> and probably others.
>
> Yes, it is a pity that we cannot solve this problem; but this is the
> problem any application developer have, and there is currently no
> unique solution under Linux; so, leave the choice to the future LADSPA
> programmer !
>
> The only thing that is needed is a way to "package" together different
> things; here i strongly encourage to use standard packaging tools, to
> avoid fixed choice like having local subdirectories in a big tar file
> with different type of elements; this can be incompatible with other
> tools (like the man pages may probabily better go in the /usr/man
> directory structure); a tool like rpm (or the debian equivalent) have
> very good solution for this kind of problems.
>
> A final suggestion: those interested in the XML based interface can
> start to think about it not as a part of LADSPA but as *client* of the
> LADSPA specification (divide and conquer again here); in this way they
> can produce a set of requirements on the LADSPA API that can help in
> making it generic and orthogonal, but keeping the two subproblems
> independent and orthogonal; in this way the XML based GUI is just
> "another" proposal to LADSPA application developer, with its own
> advantage and disvantanges depending on the situation, but it
> does not impose any specific constraint on the LADSPA architecture.
>
> Maurizio
>
> --
> Maurizio De Cecco
> MandrakeSoft http://www.mandrakesoft.com/
This archive was generated by hypermail 2b28 : Fri May 26 2000 - 01:36:17 EEST