On Thu, 20 Jul 2000, Kai Vehmanen wrote:
[...]
> > OTOH, you'll need to centralize disk access anyway to deal with more
> > than one stream per HD efficiently, so the more complex API will
>
> And this is just what I have done. I just want to keep the complexity
> hidden. If you get carried away, and mix threads, scheduling, etc with
> higher level design, your program will end up being a very complex,
> unmaintainable beast. ;)
Yeah... Dealing with such a beast at work. The worst part is that
it's written in C++. Not the right way, that is! *heh*
> Of course, in some cases you really should just hack away. I've been
> doing lots of kernel-space programming recently, and I admit, it's a
> different ball game. When you have under 10000 lines of code,
> maintaining these hacks is not a problem.
The problem with that small apps is that designing them in a "nice"
way would take 3 times as long as just hacking away...! :-) (Not to
say small programs cannot have nice designs, but heavy OO is not an
option. Unless you have a suitable object library that you know very
well, that is...)
> But unfortunately most
> (interesting) audio apps are big projects, and sw design issues become
> very important.
Yep. BTW, has anyone realized that plugin based designs aren't just
about splitting applications up into separate, pluggable binaries? ;-)
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> [EMAIL PROTECTED] -'
