Subject: Re: [linux-audio-dev] BeOS everywhere
From: David Olofson (audiality_AT_swipnet.se)
Date: ke tammi 26 2000 - 22:52:32 EST
On Thu, 27 Jan 2000, Fredrik wrote:
> i'd love to see commercial audio apps on linux, but if Steinberg
> ported their VST-based apps to linux, where would that put MuCoS?
In the middle of yet another proprietary vs. Free/Open war.
What that means depends on how superior MuCoS will be to VST 2.0,
how important the true Free/Open license of MuCoS is to developers,
and how Steinberg views MuCoS.
Technically, VST and MuCoS could coexist, and it's probably not all
that complicated to hack run-VST-plugins-under-MuCoS and vice versa
adaptor plugs (it's been done for VST/DirectX for example), but it
would probably mean a slight performance hit, and a significant loss
of flexibility and "seamlessness", compared to an all VST or all
MuCoS system.
There is a risk that Steinberg goes the VST way, as;
1) It's less work for them
2) It's easier for 3'rd party plugin developers to port plugins
3) It gives them more control over the situation
Unfortunately, this could also mean that;
1) Users lose flexibility and integration smoothness
2) Users get slightly more tied to Steinberg solutions
3) Developers get a messier (older, extended) API
4) Real, useful application integration will never happen
5) Only features that benefit Steinberg goes into the API
We have seen it all before.
Who is the big loser?
Who wins in the long run?
Anyway, the risk of this sort of competition coming up, makes it even
more important to make MuCoS not just technically superior to other
APIs, but also easier to develop for, and more solid and easy to use
for end users. That might mean that a little performance will be lost
to simplify things, or to allow for more flexibility, but I'd rather
have that than no truly useful multimedia integration API at all.
The biggest problem for us is probably time. We can't put people on
MuCoS full time to get it working a soon as it could be, so we might
well lose the first round to VST due to being late with a working
alternative.
This is the way it's always been with Free Software, but I believe
some more "Worse is Better" and a little less of Creating the Perfect
Design could help - working but ugly code is better than no code at
all. However, there also has to be a chance of fixing that ugly
code... (The problem is that the performance requirements eliminate
most chances of abstraction of the internals on the API level.)
Well, back to work...
//David
.- M u C o S -------------------. .- A u d i a l i t y ----------------.
| A Free/Open Multimedia | | Rock Solid, Hard Real Time, |
| Plugin & Integration Standard | | Low Latency Signal Processing |
`------> www.linuxdj.com/mucos -' `--> www.angelfire.com/or/audiality -'
.- D a v i d O l o f s o n ------------------------------------------.
| Audio Hacker, Linux Advocate, Open Source Advocate, Singer/Composer |
`----------------------------------------------> audiality_AT_swipnet.se -'
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST