Subject: Re: [linux-audio-dev] Re: Fwd Windows vs Linux, VST vs Mucos etc
From: Benno Senoner (sbenno_AT_gardena.net)
Date: ma helmi 28 2000 - 06:54:42 EST
On Mon, 28 Feb 2000, David Olofson wrote:
>
> However, there's no way that my design can compete with the raw
> performance of a pure "call with buffer pointers, fixed buffer size"
> plugin API. (Although it will eliminate the massive increase in
> function calls when two plugins need to communicate large amounts of
> "state changes". This is handled by buffering up timestamped events.)
>
> What I'm trying to do is to create something that's slightly more
> efficient than VST in real life use, easier to develop for and much
> more flexible. This will probably do for lots of things, but I doubt
> it can be efficient enough to be used for ultra low latency and
> short feedback loops in production systems. (Ok, CPUs get faster and
> the signal processing already uses much more CPU than the overhead in
> most applications, but some hackers will always complain... ;-)
But the short feedback loops issue is a problem in VST too (I think).
Anyway I think that the most common use of plugins is to pass
audio data between each other (DSP processing), and/or
handling events (like MIDI events) to synthesize/manipulate audio data.
>
> I think the second API will fit very nicely into the "bigger" API
> (what is currently, ahem, "known" as the MuCoS API), inside
> "operator container plugins", that look like what an engine would use
> to connect one plugin with another in another engine accross the
> network; a gateway plugin. That way, the containers can be made to
> look like simple, but still normal MuCoS plugins, without doing their
> own event decoding - the operator container does that part for all
> operators it hosts.
I think that at the beginnin, we should give to the operator related stuff less
priority than to the general plugin API.
>
> > What we could provide meanwhile is a way to "import" VST plugins,
> > like the DirectX to VST translator under Windows, so that a Mucos host can
> > run VST plugins too.
> > And looking at the technical details , I think that it wouldn't be too
> > difficult to implement.
>
> Should be possible, but I'm not hoping to be able to run the Windows
> binaries. Most of these, AFAIK, use the Windows APIs directly (for
> the UI), so some vendors might even have to do quite some porting
> work to get their sources to compile. (There *is* a UN*X version of
> the SDK already, but that doesn't help much unless you're using the
> VST GUI stuff...)
My goal was not to being able to run unmodified windows binaries
(although it would be possible using WINE + smart tricks = see Yamaha VFQ
windows plugin which runs under xmms under linux :-) ),
but give to windows VST developer an easy way to port their plugins from
windows to linux.
For this we would need:
- port the VST API headers to Linux (not a big deal I think)
- port the VST GUI stuff to Linux
(if the winows plugins use windows specific
stuff, then the programmer has to rewrite the GUI part)
- implement a VST-to-MuCoS mapper ( the real challenge)
With such a framework is would be quite easy for a windows VST-plugin developer
to port his work to linux. (except for the GUI stuff if he uses windows
specifics calls)
As far as it concerns the licensing issues, I don't know if we could get in
trouble if we write such a VST-to-MuCoS mapper.
Any clue ?
But anyway with such a mapper we have the best of the two worlds:
VST compatibility (hopefully 100% :-) ), and a flexible GPLed audio API.
Looking at this page, seems that Steinberg is considering Linux as a future
platform :-)
http://service.steinberg-na.com/knowledge.nsf/show/computer_platforms
Benno.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST