Subject: [linux-audio-dev] The future of XAP? (was: fruityloops on linux?)
From: David Olofson (david@olofson.net)
Date: Fri Jan 31 2003 - 00:54:40 EET
On Thursday 30 January 2003 22.46, Tim Hockin wrote:
> > > Iīm not a programmer, but If I were, Iīd try to do some
> > > co-operation with
> > > fruity-developers and do an linux-support to the fruityloops.
> > > īcause itīs
> > > only the question of time&money.
>
> I've tried - I offered to do it under NDA for free. They turned me
> down because "It would be too hard to explain the code to someone".
> That says to me that it is crappy code that the developer (one
> guy) does not want to document.
Crappy code should be *fixed*, not documented, BTW. ;-)
> > It would be better to write an open-source program from scratch.
>
> Which is why I got into defining XAP. Help design XAP, then a good
> Fruity clone on top of it.
Yeah. And speaking of which, what's going on ATM?
As usual, I'm hacking furiously on Audiality, which is kind of related
as it's as close to a working prototype it gets right now (I'm even
tracking the latest fads in XAP control ramping ;-) - although it's
not *only* event system stuff I'm messing with. Must get ALSA 0.9
support working, and I've been playing with that new reverb, cleaning
up a little etc...
Anyway, I've been thinking about XAP and this Unified effort. A few
facts, assumptions and questions:
1) We don't have *any* serious instrument plugin API
on Linux, and we have waited long enough already.
2) Some of us have spent countless hours thinking about
this stuff, hacking similar things etc.
3) XAP is almost ready for alpha implementation, wheras
this new API is, AFAIK, 100% vaporware, if even that.
4) What is more likely to have effect on things?
a) Documents and comments from some mailing
list members who got themselves an MMA
membership.
b) A tested and working plugin API that's
used in real applications.
c) A tested and working plugin API that's
used in real applications, and is backed
by MMA members.
What I'm saying is basically that we have nothing to lose, and
possibly a lot to win.
The worst situation we can end up in if we go ahead with XAP is two
plugin APIs on Linux; XAP and a new, totally incompatible API. That's
still a lot better than the *current* situation on Windows and Mac
OS.
The alternative is to sit back and wait while people get tired of
waiting for Linux audio to mature, or some company throws a
proprietary API in the mix, and/or forces some old legacy crap from
Win32 or Mac OS upon our platform of choice.
Given the time frames we're talking about here, and that XAP is almost
in alpha (if that term applies to APIs), I don't really think there's
more than one sensible choice here. Most of the thinking is already
done, and we *need* that API, yesterday.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
This archive was generated by hypermail 2b28 : Fri Jan 31 2003 - 01:03:22 EET