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

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] The future of XAP? (was: fruityloops on linux?)
From: David Olofson (david@olofson.net)
Date: Fri Jan 31 2003 - 16:47:29 EET


On Friday 31 January 2003 02.44, Tim Hockin wrote:
> > > 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 should be both fixed AND documented

Well, yes. What I'm saying though, is that documentation is not a good
substitute for readable, structured code. Preferably, structure,
naming etc should make the code understandable without the need for
explaining everything in comments.

The problem with comments is that they all too often describe what you
*think* the code does, rather than what it's about...

> > > 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?
>
> I'm speccing. The mess of changes to the header were losing too
> much detail, so I am writing the spec first :) Hopefully will have
> a Table of Contents and draft this weekend.

Ok, sounds good.

I'm in the process of getting Audiality to work with Rosegarden, which
includes implementing ALSA sequencer support in Audiality, and doing
some work on Rosegarden's event list editor.

Next, I plan to switch to what I call "Unified Events" throughout.
These are events without explicit action codes, using cookies for the
*full* encoding of both action and target. I'll give the event
receiving units a minimal API to request cookies for controls and
actions, and then ditch the current mess that is action codes and
control indices. Control setting and ramping is done with a single
RAMP event.

I plan on using controls for *everything* as the basic design goal.
The START and STOP events (corresponding to note on and off) will be
replaced by a single "gate" control, and I *think* I'll implement
VVID attach/detach as a control that looks at the value to decide
what to do. I'm not happy with the idea that this control actually
messes with the VVID rather than a voice control value, but this
approach seems to have other advantages. Remains to see if they
outweigh this minor ugliness.

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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Jan 31 2003 - 16:53:11 EET