Subject: [linux-audio-dev] The dangers of a do-it-all solution (long)
From: Maurizio De Cecco (maurizio_AT_mandrakesoft.com)
Date: Thu May 25 2000 - 13:38:59 EEST
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 : Thu May 25 2000 - 19:36:02 EEST