[linux-audio-dev] The future of XAP? (was: fruityloops on linux?)

[David Olofson]

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