Bill Schottstaedt is the author of Snd, a hard disk recorder and sound editor for Linux. Here we talk to Bill about Snd's history and what's coming up as well as the joys of GUILE and GUI programming.
related links:
Snd
CCRMA at Stanford
GUILE
Motif
Palo Alto, CA
M station:
How did you come about to start work on Snd? Was it
one of those things
where you started with the idea of getting something small done and then
it took on a life of it's own?
Bill Schottstaedt:
Back in the early 80's I wrote a sound editor for CCRMA's PDP-10-based
system as a part of a set of compositional tools (my background is in
composition). When we moved to Unix on NeXTs around 1990, all of that
code was flushed (it was written in SAIL, an obsolete Algol language).
There were no reasonable sound editors available on the NeXTs, but I
procrastinated for about 6 years, hoping someone else would do the
work. Finally in 1996 I decided to go ahead and write my own. By
that time we were using SGI's, so I wrote the initial version using
Motif and C. I would have preferred to use Lisp, but there were no
good Lisp GUI choices. My initial goals were modest: multi-channel
waveform display with FFTs, and a few simple editing operations. But,
as usual, the thing grew and grew. The most important mid-stream
change was the incorporation of Guile as the extension language.
I had originally written a simple-minded string-based customization
language, but after moving to Guile, it began to dawn on me that Snd
could be completely programmable. This possibility provided the
emotional charge to keep plowing away; I could feel I was doing
something new and off the beaten track, not just another editor full
of flashy effects. Since Guile implements Scheme, a variant of Lisp,
an additional benefit was that Snd fit better with the other Common
Music tools I was working on (Common Music is Heinrich Taube's
Lisp-based composition environment; I've written two ancillary parts
of that system known as CLM (Common Lisp Music), a sound synthesis
package, and CMN (Common Music Notation), a music notation package).
This prompts a few questions! ... If you were to sing the praises
for Guile, what
would you say about it? Does Guile get any AI functionality from Lisp through
Scheme? ... this might lead into what CLM does...
GUI programming is a recurring headache for programmers working alone on
projects where the idea and spur for the project is some sort of functionality.
I
remember you saying on l-a-d that you didn't care for it much. What's your
current favorite of GUI toolkits?
I think Guile is the best available extension and scripting language. Although based on Scheme, it has borrowed a lot from Common Lisp (much of the object system called goops, for example), but more important from my perspective, it gives easy access both to C code and to underlying operating system functions (this is not the case in Lisp or Scheme; Lisp's foreign function interfaces are a nightmare). In a sense, it doesn't get in your way as much. And with guile-gtk, it has a reasonable GUI package (also lacking in its ancestors). Its main drawbacks are that it doesn't yet have a compiler, so signal processing code is slow, and the interaction of the garbage collector and the C compiler is hard to understand. Librep (an extension language that implements something closer to Common Lisp) has a byte compiler, and is close enough in spirit to Guile that I made a macro package that tied most of Snd's Guile-isms into it. But Librep is not as fully developed as Guile (no setf or defmacro for example), and I found it very hard to debug anything. Ruby is also very similar in the approach it takes, and I think a similar header file of macros could make it run with Snd, but I haven't had time to dig into it. Neither Librep nor Ruby are well documented (from the extension language point of view, of course), so you have to spend much time groveling through the sources.
On the GUI toolkit issue, I think Motif is the best available; it has more functionality than Gtk+ (particularly in the text and paned-window widgets), fewer bugs, and is much more fully documented, and the resultant images run at essentially the same size and speed. Its main problem (besides politics) is its somewhat old-fashioned programming interface using "resources". But the functional approach used by Gtk+ is just as verbose and cumbersome, and really only replaces XtSetArg calls with gtk_ function calls. Gtk+'s callbacks are badly designed, in my opinion, so you sometimes can't tell (and neither can the compiler) how many arguments are supposed to be passed, leading to segfaults long after you thought the code was solid. And I still don't understand how you're supposed to set a widget's colors -- there are at least 35 separate semi-documented choices, none of which seems to work reliably. I find both extremely tedious to work with, partly due to the repetitive "cut-and-paste" programming required, but more importantly that if you want to do anything even slightly unusual you have to flail around with endless experiments, trying to guess what sequence of calls the developers have chosen for the functionality you're searching for. In Gtk+, I spend most my time running fgrep over the sources, and then I end up using whatever the toolkit insists on giving me, rather than getting the interface I actually want. But my interests are more in the area of sound processing than user interface design, so perhaps I'm not patient enough.
For a beginner wanting to get into sound processing what texts
would you recommend?
Could you say a little bit about what CLM does? Is it an algorithmic composition
tool ... does it make 'choices' within itself ?(getting back to that Lisp->AI
thing).
I think we use "Computer Music" by Dodge and Jerse for teaching here at CCRMA. There are several other good books available; one by Eduardo Miranda comes to mind, but I've forgotten its title; also Steiglitz's "A DSP Primer", and Lyons' "Introduction to DSP".
CLM is a sound-synthesis and signal-processing package in the Music V family; it is similar to Csound in the kind of activity it tries to support, though with perhaps less emphasis on real-time work, and more on tape-music styles of composition. It has all the usual "generators", most of them a direct outgrowth of Mus10 (the earlier Music V package used here). CLM doesn't directly support algorithmic composition (that's more the bailiwick of Common Music), but provides the underlying sound-producing functions such as with-sound. Since it's all Lisp, the composer can use Lisp (loops etc) to write algorithms that then call CLM "instruments" (which are themselves written in Lisp). A C version of the package is built into Snd, providing nearly all the editing functions and sound-effects, as well as the real-time operations of the "control panel". It's also possible to run these instruments with real-time controls from guile-gtk, and so on.
Just as an aside, with your own music is your prime interest
in the technicalities
of producing it or with aesthetic rules? Or neither!
I haven't written any music lately -- not completely sure why, but in the past my main interest was making expressive music. If it gave me goose-bumps, then I felt I was on the right track. I enjoyed the technical sides to the process, but didn't obsess over them. I used algorithmic composition as a sort of exploration or improvisation tool, a way to try out new ideas and see if anything good turned up.
With Guile making Snd almost infinitely extensible there are
probably some areas you'd
like to see more work done in. What are they? (if they exist!)
There are lots of loose ends and unexplored possibilities here; I almost try not to think about it -- there's a sense of vertigo at how much needs to be or could be done. Looking into one such abyss, Snd is a sort of user interface for CLM, and the two could be much more closely integrated. The instrument-definition and instrument-grouping possibilities of CLM in Scheme have scarcely been touched yet. Each time I look at this, I have a feeling that there is something not yet crystalized here that I really ought to tackle somehow; a vein worth mining, so to speak. And the edit-history aspect of Snd in connection with CLM has always struck me as almost endlessly powerful. I used to keep elaborate records of every change I made in an on-going composition, so that I could back up if needed. Now, this entire process could be automated. Tie in CMN and CM, and we could end up with a very nice compositional environment. Rick Taube and I are sort of working at this from opposite ends of the problem. Then there are many short-term things that need attention. One obvious one is that Snd and CLM have been evolving, making some functions obsolete or useless, and creating inconsistencies between others; eventually I need to clean up this mess. In the sound processing world, Snd needs noise reduction, a better version of the time stretching algorithm, some way to remove or add vibrato or change the pitch of one note in a recording, or remove a voice from a mix, fancier filters and the user-interface for designing them, MIDI support, prettier spectrograms via openGL, a graphic EQ dialog, and on and on! My "todo" list has more than 100 entries, and never seems to get shorter.
I guess it isn't a great leap to think of any sound editor as
a composition tool but
it seems that Snd has great possibilities there. Do you use it that way yourself?
You've struck a bit of a sore point! I haven't written any music using Snd. I used to preach at others that a program like this only gets better if the programmer actually has to use it in real work, and here I am doing nothing but programming. I consider this a serious problem, but one that is harder to deal with than it might seem. Programming is much easier than composition, and the results of the work get instant positive feedback from users. In music composition on the other hand, especially in the "new music" or "serious music" world, you're lucky to get even a bad review; the norm is to slave away for months, get a performace or two, and a few friends pat you on the back. After ten or twenty years of this, you begin to lose heart. And I'm much luckier in this regard than many of my composer friends, since I am under no pressure from my employers to do something useful. Most of my friends are either buried under ridiculous teaching loads, or trying to juggle a family and a programming job and still write music on the side.
That pretty well covers the immediate future for Snd I think...
a fair bit
of work there! Do you have anyone else contributing code?
Yes, a number of people have sent me code; the main helper is Fernando Lopez-Lezcano who's handling the ALSA support; the original version of that code was donated by Paul Barton-Davis. Richard Furse sent me a large block of code to support LADPSA, and Nick Bailey sent ESD code. Many people have sent contributions to CLM/CMN, in particular Anders Vinjar, Marco Trevisani, Michael Edwards, and Rick Taube.
One of the things I'm interested in is the concept of tools altering
not
just the way we work but what we produce as well. It seems that large
programs like Snd have a potential to do this where certain combinations
of functionality come to the fore somehow. Have you heard of Snd users
doing anything interesting?
I get very little feedback of that sort. Composers seem to be reluctant to describe exactly how they use these tools. We've had discussions on cmdist (the Common Music mailing list) about setting up some sort of repository of pieces, showing how composers are using the software, but the general response seems to be that the compositional process is so messy and chaotic that there is rarely a clean, easily-followed sequence leading to the final music. I guess this is a sign of success, since we hope to support an open-ended, exploratory mode of work, and that is unlikely to be tidy.
I notice that some people are doing or thinking of doing, ports
to Mac OS X.
Do you have any thoughts that way?
Yes, it's "on my list"! I got Snd (and Guile) to compile on Mac OS-X a few months ago, but at that time Gtk+ wasn't available, and I ran into some file system problems. We're planning to have OS-X running here at CCRMA, so I'll definitely try to port all my software.
I'll be out of your hair soon Bill. If there are aspects of things
that you'd
like to mention that I haven't brought up, feel free to prompt me.
I can't immediately think of anything -- if it could fit in somehow, I'd like to mention that developing free software has been a real pleasure; in all these years I've had only friendly and helpful responses from users and other developers; even developers of commercial products in the same overall area as Snd have answered my questions in an open and friendly manner. The audio software world is amazingly "collegial". Perhaps only people who love music get into this business.
Thanks very much Bill.
|
|
|||||||
|
|