[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sound header

I understand.  I'm going to be sitting down with the sound team this
weekend, and we're going to discuss all this, but honestly, classes,
dataflow, functions, etc. will change quite a bit, and while I do want to
document things in detail, I want to do it gradually...basically we say
"Okay, code to access /dev/mixer is finished, tested, debugged, and runs
great, now let's write up how it works."  The stuff I've written so far was
called a design doc, but I will say right now it was a misnomer.  It's a
.plan file. If you want a more detailed doc, it's on the way - after I sit
down with the sound team and we decide how thing are going to run.


At 10:28 AM 4/1/99 +0300, you wrote:
>On Wed, 31 Mar 1999, The Greene Family wrote:
>>Since I have not recieved any objections to the current plans, I will be
>>releasing a header file soon.  I have already been workin on mixer
>>functions (such as volume et cetera. )  I also have a couple people who
>>have contacted me about helping with sound, working on some things.
>Somehow I don't think that an API specification and design is covered by
>'one headerfile'. I think more designing with paper and pen is needed. The
>relationships between objects and classes, dataflow, events and so on need
>a tiny little bit more design than one 1kB document and a headerfile. If
>these parts are designed badly nobody will use it and go straight with the
>libraries 'sound' will be wrapping.
>This is not meant as a flame, but sometimes this kind of stuff needs more
>planning. I use to do too fast decisions myself, and later suffer the
>consequences and regret the bad planning.
>Just some comments....
> Jan 'Chakie' Ekholm |    CS at Åbo Akademi University, Turku, Finland
>    Linux Inside     | I'm the blue screen of death, no-one hears you scream
>To unsubscribe, e-mail: penguinplay-unsubscribe@sunsite.auc.dk
>For additional commands, e-mail: penguinplay-help@sunsite.auc.dk