Re: [linux-audio-dev] Re: Fwd Windows vs Linux, VST vs Mucos etc

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: Fwd Windows vs Linux, VST vs Mucos etc
From: David Olofson (david_AT_gardena.net)
Date: ma helmi  28 2000 - 19:10:33 EST


On Mon, 28 Feb 2000, Benno Senoner wrote:
> But the short feedback loops issue is a problem in VST too (I think).

Yes; actually, you can't even do it properly, as you don't know the
delay of the plugin - still no such property in VST 2.0 as far as I
could see in the SDK!

> 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.

Yes, but even here, a "basic" plugin system has the advantage that
there's just one function call for each buffer - no events processing
or anything. However, that performance advantage diminishes as more
than pure processing with virtually fixed parameters is required...

> > 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.

Yes, and I don't think that's much of a problem. As of now, it seems
to fit in rather nicely, so I'm not expecting that part to force any
significant changes to the higher level API.

> 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)

More or less done already, I think! Check out the SDKs...

> - port the VST GUI stuff to Linux
> (if the winows plugins use windows specific
> stuff, then the programmer has to rewrite the GUI part)

Yep... BTW, this is where that QPL problem might come in, if an
implementation would be built on Qt. What happens? Who pays the
licence!? (Qt *is* used by proprietary, closed source code in this
situation, although indirectly, as far as I can tell...)

> - implement a VST-to-MuCoS mapper ( the real challenge)

There will be some mapping mess for the VST 2.0 event system, but the
audio buffers can be handled pretty easily, unless I'm overlooking
something. This function call <-> event mapping thing might reuire
som work... Don't know if it's actually *complicated*, though - but
there are quite a few of those functions to take care of, and they
probably won't map 1:1 to the defined events of the MuCoS API.

(BTW, the last few days I've been working on Object Pascal code
that does a similar thing; interfacing a new API with an old, crappy
serial communication protocol... Seems to work now, but all those
translations and remappings... Ouch! It looks pretty nice from the
API side, though. :-)

> 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)

Maybe some "Win32 GDI compatibility layer" would come in handy here?
Not that I like to have that kind of stuff around, but developers in
general don't fancy rewriting GUI code either... That can be a very
large share of the total amount of code!

> 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 ?

Haven't read the licence agreement that carefully, as I never
intended to actually use the stuff... Does the plugin SDK licence
mention hosts at all?
 
> But anyway with such a mapper we have the best of the two worlds:
> VST compatibility (hopefully 100% :-) ), and a flexible GPLed audio API.

Well, if it's actually easier to port the plugin to the framework
rather than to MuCoS, and that framework doesn't requiring half a
Windows emulator, it makes sense. :-)

//David

.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST