Subject: Re: [linux-audio-dev] User Interface
From: Paul Davis (pbd_AT_Op.Net)
Date: Fri Jul 27 2001 - 15:57:01 EEST
>The library of useful ideas for each project are reasonably sized but
>nothing as extensive as the code base for win or mac editors. But if we
>had combined them all from the start then we would already have a very
>strong editing suite. How unrealistic is it? Is that posibility just too
>fantastic?
The list of editing operations that one can perform is actually very
small. Basically: insert, remove, replace, transform. All other
editing operations are just built on these basic blocks.
The problem is that it *really* matters what the underlying data
representation is. Almost all existing Linux audio editors assume they
are working on linear sample streams. At some point, this abstraction
has to exist, since thats the form required for playback to the device
driver. But the details of how a particular operation is carried out
may vary widely depending on the actual internal representation.
This means that you can't just take an idea (let alone code) from one
project and apply it to another one instantly. In fact, its always a
measure for me of how good (or bad) my code is to see how difficult
implementing an idea I did not have at the time I wrote it turns out
to be. When its easy, I get a nice warm feeling all over. When its
difficult, I end up being suspicious about the entire codebase.
To give you a specific example: in ardour, when you insert an audio
file into a track, the operation you have performed is *nothing* like
what happens when you do that in sweep or gnoise or audacity. there is
no data copying, the only thing that has changed is a playlist.
Now, a playlist is the "natural" form for audio editing, as we can see
in the MacOS/Win world. But a playlist is a much more sophisticated
structure than a linear list of samples, and programmers differ
greatly in how they want a playlist to be implemented. Some would want
such a thing in C, some in C++, some would want it to have certain
properties, a specific API etc.
Now, if someone produced a library that supported playlist editing in
C in a way that could be easily integrated into (1) other languages
(2) programs with different goals, there would be chance at
"cooperation", since we'd stand more chance of working on the same
data structures. I'm not a long way from that possibility, but its not
one of my current goals, either.
--p
This archive was generated by hypermail 2b28 : Fri Jul 27 2001 - 15:54:12 EEST