Subject: Re: [linux-audio-dev] defending simplicity
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Wed Mar 29 2000 - 20:46:49 EEST
On Wed, 29 Mar 2000, Paul Barton-Davis wrote:
> Lets all say it again, slowly
>
> d e f e n d i n g s i m p l i c i t y
Sorry for being a perfectionist, but don't think that I am
unable to make compromises. Real world stuff need some
compromises and the imposing of limits.
My emphasis is maybe too much on the flexibility and extensibility side,
but I don't see this as a big disadvantage.
>
> Now lets move on to some quoted text:
>
> >LADSPA1 will be simple, but LADSPA2 will follow soon (hopefully) and
> >will have many nice features, including full LADSPA1 backwards
> >compatibility , (that means LADSPA2 hosts will be able to run LADSPA1
> >plugins) (hopefully) full VST1 AND VST2 wrapping, that means, there
> >will be VST headerfiles and a library which will allow allow to
> >recomplie VST plugins to LADSPA2 plugins which can then run without
> >any performance penalty under a LADSPA2 host.
>
> Benno, sorry my friend, but you're on a different planet than the one
> I am on. We don't even LADSPA yet, and you're now talking about
> LADSPA2, libraries for VST which are not needed, all kinds of stuff
> which is just *crazy*.
Yes too premature, but some thoughts, what could be done with not too
much effort.
>
> Right now, we don't have LADSPA, and discussing the future in this way
> strikes me as
>
> 1) making a mockery of the development process
> 2) creates uncertainty in the minds of anyone considering
> adding plugin support
Isn't LADSPA1 about to be officially released ?
That means the plugin developer can use LADSPA1 or if it feels
better using VST1/2 , he can go that way.
As said before and even if you (and maybe some other people) do not
like this, I plan a wrapper for VST1/2 to LADSPA2 , so that LADSPA2 hosts
can run VST1/2 plugins transparently.
To do that, LADSPA2 has to provide a superset of the VST2 functions,
and I think the event handling proposed by David Olofson, can easily
accomodate the MIDI-in functions provided by VST2.
>
> Furthermore, suggesting all this stuff about how to handle VST is
> premature. There are perhaps 3 LADSPA "toy" plugins in existence right
> now, versus at least a few hundred serious ones for VST.
I agree here, and this is exactly the point, why I am going the wrapper
way: to take advantage of the hundreds of existing plugins for VST
at really little cost. (both in terms of CPU overhead and complexity of
the host code)
> Talking about
> how an upstart API should host the leader in the field strikes me as
> completely upside down.
Yes, that is somewhat brutal, I agree, but on opensource often, the community
sets the standard, but again , I am speaking of the community, not the thought
of one single developer ( me or you for example :-) )
>If we want to talk about VST (which I do), the
> discussion should be on how it could be extended in a 100% compatible
> way to provide support for things like multiple data types, spectral
> data, and so forth, as well as how to deal with Steinberg's licensing
> arrangement and requirements.
As you see we have two problems here: solving the licensing issue,
and "patching" an existing API ( VST) to include objects which may
cause troubles ( breaking of legacy apps, duplication of functions,
since the initial design was not flexible enough, etc)
>
> Richard himself said some time ago that if we had VST for Linux, there
> would be no need for LADSPA. Please keep this in mind.
Why exacty VST, we could have borrowed almost any windows API,
(DirectX, EASI etc).
Anyway I have still to study the VST2 PDF extensively,
so I can tell you my exact opinions about the API.
It would be nice if other people could express their thoughts on this
discussion.
It's some sort of adopting/cloning de-facto standard vs from-scratch
implementation.
Applying this concept to operating systems:
opensource developers need their own operating system:
1) since Windows is the market leader, reverse-engineer it and make a
free-clone, fully compatible with the original one, thousand of programs
will run on the free-OS
2) write a better one from scratch: Linux is an example
less pain, much more power , but windows apps will not run natively
use a "wrapper" like Wine to achieve backwards compatibility , although
with some drawbacks (slower performance,some compatibility problems of
certain apps)
an audio API is certainly ORDERS OF MAGNITUTES simpler than Windows,
therefore the "wrapper" can be made almost perfect.
Sorry for insisting on the second solution, but Linux gave us the proof that it
works , and I don't see why it shouldn't work with an audio API which is a toy
compared to an operating system.
Benno.
This archive was generated by hypermail 2b28 : Wed Mar 29 2000 - 23:12:26 EEST