Subject: Re: [linux-audio-dev] discussion about development overlap
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Tue Sep 26 2000 - 21:52:33 EEST
Kai writes:
>It's a well-known fact that there is lots of development overlap in the
>Linux audio-dev scene.
A good subject for email ... especially as I am currently adding
real-time CD recording to ardour, and very disturbed by the amount of
pipe(2)/fork(2)/exec(2) calls i have to make so that i can use
cdrecord ...
>Why I'm writing is that during the last few weeks, I've managed to come up
>with a _huge_ list of audio-related items to my todo-list. Unfortunately I
>know for sure, that I will only have time to implement a few of them. So
>it would make sense to concentrate my energy on items, which don't overlap
>with other people's doings. And I'm sure I'm not the only one in this
>position.
No, but lets start with the first thing on your list - MIDI:
>So far I have identified the following items/features:
>- support for multiple independent MIDI-devices
>- support for different types of sw-level MIDI-interfaces
> (at least OSS rawmidi, ALSA rawmidi, ALSA sequencer, pipes)
>- MIDI-CC input mapped to effect and controller parameters
> (this is already implemented)
>- MTC input (start, stop, continue, possibly time-code (is MTC
> accurate enough for above purposes?)
>- MTC output (same as with input)
>- MIDI-CC output (does this make any sense?)
>- custom MIDI messages (this might allow to replace keyboard
> and mouse, with a MIDI-gadget; but is this worth it?)
Your list is completely covered by libmidi++. Any questions ?
:)
>For instance, I try to close follow Ardour development. At least now, Paul
>and I clearly have different target audiences. I take this into account
>when doing ecasound design decisions. Ardour-like features have very low
>priority.
Very much understood.
>Another issue important to me is audio editors. I'm still a happy Snd
>user, but at the same time, there clearly is a market for a more
>straigthforward (=simple) editor. My ecawave project started as an
>experiment. Mainly I wanted to show that it's easy to write a standalone
>audio app on top of ecasound libraries. But lot has happened since, and
>with the latest dev-release of ecawave, it's starting to be usable for
>much more than playing around with LADPSA plugins. But, but, I'm not sure
>what the current sound editor situation is... what editors are you using?
>Should I continue to work on ecawave, or should I concentrate on other
>projects? Anyone interested to join the project?
Well, I am really split on this. snd's generality and history is a
huge plus. OTOH, its internal design and some of its strong
connections with sndlib's audio I/O stuff are a weak spot for
developers, and its GUI, though not hard to rearrange (i'm talking
about the GTK+ version) needs a more-or-less complete redesign. I
would be slightly more enthusiastic about an attempt to do this than
yet another "somewhat functional but definitely new" editor.
having said that, proper support for EDL's for multichannel editing
will be a big issue for me in the new year. right now, snd's handling
of this stuff is not really very clean (there is a deep assumption
that streaming from disk is simple), and i am not convinced that
fixing it is less work than writing it from scratch (and reusing code,
of course). so if there's a chance that ecawave will have the kind of
clean design that will permit full use of EDL's, i would welcome that
kind of "new project".
>Audio servers are another issue. One thing that I find curious is that
>aRts still hasn't gained much support outside the KDE world. Why is this?
my own answer would be that its been presented as *too* capable. most
people just want a soundserver that multiplexes audio streams to some
PCM device. aRts does *so* much more than this that no matter how good
a job it might do of the multiplexing, it intimidates most people
(including me!).
--p
This archive was generated by hypermail 2b28 : Tue Sep 26 2000 - 22:16:57 EEST