Subject: Re: [linux-audio-dev] a letter for review
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Thu Apr 06 2000 - 01:43:11 EEST
On Wed, 05 Apr 2000, Paul Barton-Davis wrote:
> I don't think there's much point any more in trying to hide the fact
> that I am in touch with Steinberg, and discussing the possibilities
> for Linux as a platform for their products. Below is the first draft
> of a letter I am going to send them. Your editorial comments are
> welcome.
>
> --p
I am not very convinced by the "extending-VST" strategy,
you will end up in a half effect plugin API + unit generators hacks.
My proposal remained unchanged:
- hosting or writing "pure" (=unchanged) VST2.0 plugins is free for all,
whether you are writing an opensource app or not.
- adding a bit of infrastructure in order to ease VST2.0 wrapping
does not lead to licensing issues (IMHO).
A MuCos-like API (based on LADSPA) can easily wrap VST2.0 plugins,
with almost zero overhead.
MuCos hosts would have very little additional work to do, in order to host
VST2.0 (since the wrapper-lib takes care of almost all issues).
Steinberg is free to use pure VST2.0 on Linux.
Let's say many VST2.0 plugins get ported to Linux.
Good , we can run them all in our MuCos hosts , at the same speed,
not to mention that we can run simple LADSPA plugins too.
IO think we should here take the "embrace and extend" approach used
by M$, but instead of taking the original API and extending them
(= license problems) , we fit it in our much powerful MuCos API + wrapper
functions.
I don't think VST3.0 is getting out too soon, (why change the API often?),
therefore MuCos 1.0 will allow wrapping VST2.0
and if VST 3.0 gets out, we only have to add the missing functionality.
I don't want to pray a company "can I add my kickass eventsystem etc, to your
API because we opensource developer need it, but we want VST compatibility too".
I see it as a cleaner solution to use LADSPA/Mucos to build a flexible plugin
API, than extending VST2.0.
Plus connections between ports makes many things much easier:
for example Richard's example host applyplugin.c is really simple when
it comes to run() the plugin:
just a loop where you call plugin[i]->run()
no parameters are needed since all connections are already in place.
Not to mention the flexible routing that the port concept allows,
all this without intervention by the host.
I know that Paul does not agree with my wrapping concept, but
adopting VST2.0 as the "official" API limits our choices and ideas too much.
I want our plugin API able to run on SMP boxes and clusters of parallel
machines, therefore we need flexibility from the ground up.
And this flexibility can only be gathered by the IQ-pool on this list,
rather than a single company which has its own POV.
But again, I really hope that Steinberg ports Cubase/Nuendo and VST plugins
to Linux, we can only profit from this.
Benno.
This archive was generated by hypermail 2b28 : Thu Apr 06 2000 - 02:20:55 EEST