Re: [linux-audio-dev] join LAD! (fwd)

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

Subject: Re: [linux-audio-dev] join LAD! (fwd)
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: to helmi  24 2000 - 00:48:32 EST


>Lets list programs which have a flow system -- it is easier to make
>a library initial just by extracting the codes "as is" so that nobody
>has to make big changes to their software.
>
> csound, quasimodo, arts, sonic flow, ecasound, ?

As much as I appreciate Juhana's zeal and committment to the idea of
"standard" libraries, I don't share his enthusiam for them. This is
not because I think that libraries are a bad idea; on the contrary, I
try to structure as much of what I write as libraries as I can,
because it tends to enhance both OOP in general, and what Kai referred
to as "design-by-contract".

however, libraries only work well when they do well defined
tasks. even if at some point, the tasks that an "audio toolbox"
library has to do become clear and undisputable, we are definitely
*not* at that point yet. it doesn't help to argue this point by
listing the many things that we would all agree would be useful to
have.

there is the problem is integration - in the example of "flow systems"
- how closely integrated is the flow system with output/input to some
kind audio interface ? for some programs, there are reasons to want a
very close coupling, and in others not much at all.

the choice of basic data type is another issue. some programs use
integer arithmetic only, some use floats, some use doubles. although
typedef's and/or C++ classes+templates can hide some of this, its not
very easy to write an efficient library that supports various sample
data types well.

take a look at what has happened with libraries to access
soundfiles. we have several of them, each with their own particular
quirks, benefits and disadvantages. i even reimplemented one myself,
because i could find none that (1) used mmap(2) for read access (2)
allowed me access the channels efficiently in a program that might
generate non-interleaved data but need to store the data in an
interleaved file (3) supported my kind of C++ idiom. Was I wrong to do
this ? In one sense, yes. But I decided that for my own work, I was
better off using a library that I could tune to the kinds of programs
I have been writing. If I thought I could have modified libsndfile or
libaudiofile or any of the others to be the "perfect" soundfile
library, I would have done it, but I don't think this is possible.

even the language issue gets in the way - I happen to like working in
C++ for a variety of reasons. That means that in general my libraries
are written in C++, and thus cannot be used without a lot of work by
people working in C. If libraries get written in C, then I have to
either wrap them (and keep the wrappers up to date), or deal with one
or more programming idioms that I have been very happy to move away
from.

yes, i would love it if it turned out that Quasimodo was a good enough
general purpose flow library (and don't forget - it *is* already a
library) for everyone to use. but i am not this naive. quasimodo does
not currently support sample accurate processing - if `tapiir' had
been written using Quasimodo, it would not work at all. should maarten
have hacked quasimodo so that it did do this, or was it a perfectly
reasonable and pragmatic decision to do without a library, and just do
what he needed himself ?

yes, its wasteful, but we are part of an *EXPERIMENT*. The easy
availability of enough CPU cycles to do meaningful real-time audio
work is a new thing, and we are from clear what it all means. I think
that its just fine (for a while yet) to have many different people all
hammering away on various parts of this stuff independently, as long
as we all talk to each other about what we're doing, exchange ideas,
and where appropriate, share code.

but i really cannot agree that creating standard libraries at this
point in time is a good goal for most of us. if Juhana and others
manage to do this, and somehow create libraries that don't have the
same kinds of issues as the various soundfile ones do, i will applaud
the work. but its not something i can feel good about right now.

--p


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

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST