Subject: [linux-audio-dev] Re: Fwd Windows vs Linux, VST vs Mucos etc
From: David Olofson (david_AT_gardena.net)
Date: su helmi 27 2000 - 19:43:19 EST
On Fri, 25 Feb 2000, Benno Senoner wrote:
> - VST license is proprietary [...]
...ie, if a certain feature means that end-users get lots of
extra power as a nearly free bonus, without upgrading all their
software, it's out. That's the sole reason why proprietary APIs look
like MS DirectX... As a Free/Open Software advocate/user/developer, I
can't tolerate working under that kind of conditions - it
contradicts the very principles of Free Software!
> - VST is not the best possible plugin-API as we figured out here on the list.
> ( hardwired MIDI , not very flexible event handling etc, .. just ask David
> Olofson)
Oh, OTOH, there's no such thing as The Perfect API.
I think I'm on to a design that lets you do pretty much anything
without a massive set of API definitions that every single engine and
plugin has to be aware of. (That is, you can connect two plugins that
talk 64 bit to each other in an engine that has no clue as to what 64
bit data is, for example. I mean, does Linux ext2fs have to
understand what you store in your files?)
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... ;-)
IMHO, two (integrated) plugin APIs could cover almost every aspect of
audio processing, where it makes sense to use plugins: One powerful,
flexible API with transparent connectivity accross threads, processes
and networks for the "normal" plugins, and one simple, higly
optimized API for kernel level low latency (RTLinux) processing,
Csound style modular synthesizers (very small "array operators" rather
than plugins) and the like.
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.
Does this cover what most people want to do, and want from a plugin
API?
> I am hoping that as soon as Mucos shows up (we have to exit from the vaporware
> status and enter in a pre-pre-alpha state :-) ),
Indeed... :-)
> and becomes somewhat functional, audio software vendors will join our efforts to
> improve the API, just like it happened to the linux kernel.
Well, let's just hope the flexibility doesn't scare them off. ;-)
(Seriously, there are lots of companies that are nervous about not
being able to control every single aspect of how their products con
be used. This may become an issue with MuCoS, unless we
deliberately cripple it... I hope this will be seen as "State of The
Art" rather than "Less Chance to Bill Customers for Trivial
Features".)
> 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...)
//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 -'
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST