Subject: Re: [linux-audio-dev] BeOS everywhere
From: David Olofson (audiality_AT_swipnet.se)
Date: to tammi 27 2000 - 17:12:41 EST
On Thu, 27 Jan 2000, Fredrik wrote:
> You sound very sure that VST is on it's way to Linux.
Not really, just worst case speculation, in case Steinberg really
starts to doubt in BeOS as a high end multimedia OS.
> I think it will be at least two years before a final version.
Yes, but you never know what they're hacking behind the scenes... And
there already is an IRIX version, so they could have lots of
reusable UN*X code.
> > 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.)
>
> One way to do a good design is to do a bad one first. In the words
> of Fred Brooks (The Mytical Man-Month): "Plan to throw one away;
> you will, anyhow."
Yes, I'm pretty experienced with that! *hehe* That's why there are
MuCoS "prototypes" in the works even before the API spec is available.
First, I started over with DynaTracker/Amiga 3 times - and when I
finally had a fast, simple and good looking GUI with a visual editor,
and an 8-16 ch stereo engine, I decided to leave the Amiga for the
PC... (Uhm, I'd rather not talk about that. DOS and all that... ;-)
I've already designed and partially coded (used for performance
testing) an engine pretty similar to VST 1.0 for Win16/Wint32s - and
I threw it away, partly because Windoze just wouldn't cut it, partly
because my design was way too limited, IMO.
I started over with WinNT, and thought that a recursive "request as
much data as I need" processing net design would be more flexible.
Yeah, it would but what a mess! I never even got around to code it,
as it was nearly too complex to grasp, and it was obvious that all
those function calls would kill performance right away. And of
course, NT was even worse than 95/98... (It's better now, with
DirectSound, but it still sucks. Good for toys and editing, but not
for serious recording and native processing. Why waste time with it?)
Finally, I decided to go Open/Free Source, and eventually came
here... The best move so far! :-)
With the MuCoS design, we seem to be closing up on something that
avoids both the restrictions and the complexity, while getting even
more flexibility. Still I'm counting on changing lots of things in my
version, and throwing away at least one prototype implementation. I
think working on multiple, different versions is also useful here - we
get to try more techniques before we decide what to put in the final
specification. (Besides, we're actually working on two similar APIs,
one for callback scheduling [plugins], and one for threads [clients].)
//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