[linux-audio-dev] Project advice

Steve Harris S.W.Harris at ecs.soton.ac.uk
Sun Jul 25 08:57:39 EDT 2004

Hi all,

Due to some family problems and lot of pressure at work I have not been
able to spend as much time as needed on my audio projects in the last few
months. This means that many of them have patch backlogs and TODOs with 6
month old jobs on then and I'm starting to loose track of things. The
situation will probably get worse in the next few months.

Because of this I'm going to try to move as many projects as reasonable
onto sourforge (or similar), so that there is a maling list and bug
reporting system where the outstandiing problems can be publicy seen, and
that will hopefully be more reliable than my inbox and memory :) Also for
the posibility of coding and administration assistance.

There are a few questions I have for the community though, so feedback
would be helpful:

Timemachine - the code is pretty simple, but it needs a couple of fixes -
theres a race condition that a friend has agreed to fix, and it needs some
way of switching between WAV and W64 files as needed. Its unlikly to grow
much bigger though, so I'm not sure it relly needs a proper project.

SWH-plugins - this is a biggie. Its a bit of a maintainance nightmare so it
should be somewhere other people can get at it, but I'm very tempted to
change the name, as it's a bit self publicising - a lot of the effort was
contributed by other people, and I dont want to seem like I'm claiming
their effort. OTOH, it has quite a lot of "brand recognition" (or whatever
the free software equivalent is).

Meterbridge - the code is in a state of flux, in the CVS tree I'm halfway
though a parallel graphics backed for OpenGL - it decreases the CPU load
immensly, and lets you scale meters live, which is very handy, but its a
fairly big job, and I dont know OpenGL that well. The question is wether I
should wait for the OGL port to be finished before I inflict the code on
the world.

Liblo - the most common bug report I get is that the name is too short -
so maybe that should change :) suggestions welcome, libliteosc seems
obvious, but may be not true in the future. Other than that its a
good candidate for being inflicted on the world - its actually pretty well
documented! I'm most of the way though refactoring the network code to
make it less UDP specific, and adding UNIX domain socket support. The
libtool stuff is b0rked. I think OSC is important to the future of linux
audio, so I always intended to make this a colaborative project once
it had enough momentum.


More information about the linux-audio-dev mailing list