Hi Ross, welcome.
The list is quiet right now, but there's something of a critical mass
of development projects happening now, so I wouldn't be surprised to
see it pick up soon. I'll answer and if anyone else has thoughts
on the topic they're free to chime in.
>I've just joined the saol-dev list because I'm considering implementing
saol
>as a low-level embedded signal processing design languge in my window$
>shareware real-time audio app AudioMulch (http://www.audiomulch.com/). I am
>considering saol because I like the syntax, and language design isn't my
>strong suit. I'd be interested in contributing to an existing real-time
>open-source implementation if the licensing conditions were right.
I don't know what the current status of open-source real-time SAOL
interpreters are. There was one project, but it may have gone
proprietary. Most of the other things going on for real-time SAOL
right now are compilers, and so they don't make good embedded
subsystems. If somebody wants to manage a real-time interpreter
project, I can hire some undergraduates here as programming help...
I think the framework of 'saolc' is plenty useful to serve as the
basis for a real-time implementation. I'd recommend going to a
p-code translation system, where you compile the high-level code into
a more efficient intermediate language. Also, detection of block-
processing ability would let you design block-based versions of the
core opcodes that could be very very fast.
>I know this is never a popular question, but I'll ask anyway: If mpeg-4
>compliance isn't an issue, what are the main advantages _and_ disadvantages
>of saol over other current software synthesis languages ( Csound,
>Supercollider, clm, ?? ).
An important issue here is that except for SAOL, the other three you
mention are languages *and* implementations. That is, the Csound language
isn't defined anywhere except as the set of programs accepted by a
particular piece of software. Speaking only from a language
(syntax and semantics) point of view, I don't see huge differences
among these, and differences of opinion are likely to abound.
Some of the differences are:
- Supercollider has the most powerful computer-science language model,
including closures, function-arguments, and a full object-oriented
framework. It is a matter of opinion what the relevance of this
is to musical composition and sound design. McCartney argues that
we're missing a lot of interesting musical possibilities by being
so focused on the procedural one-step-at-a-time sort of a language,
and that SC makes it much easier to do fancy things with sets of
pitches, grains, and/or notes.
- SAOL is the easiest to read, IMHO.
- CLM is the simplest to parse, followed by Csound.
- Csound is the easiest to compile, since it is really only a macro
preprocessor.
- SAOL has a formal specification that you can read to know what the
implementation is supposed to do. None of the other languages do;
none of the other languages are designed for reimplementation in
different contexts.
- Csound has a very rich, complicated and, perhaps, unusual set of
built-in unit generators. Reimplementing all of them would be a
monumental task.
Some of the non-language-syntax issues to consider are:
- SAOL is the only language without intellectual-property hangups. I
don't know what would be the stance of MIT or Stanford to reimplementing
Csound or CLM. I can guess what James's stance would be toward
reimplementing SC. :) There is freely available code for starting a
SAOL implementation, unlike the other languages.
- Csound has a much larger user community than any of the other languages.
Probably SC is next. There's essentially no-one today using SAOL to
actually make music.
- The MPEG-4 status of SAOL means that there will be a lot of other
projects around it. European initiatives will naturally gravitate
towards it when there is software-synthesis research involved. I note
that there's *already* more mutually-compatible implementations of
SAOL (two, maybe three) than of other languages. Even for a system
like yours that is not *in itself* an MPEG-4 device, in the near
future it would be able to make use of ("interoperate with" in MPEG
language) lots of other tools developed around the standard, like
graphical authoring tools and so on (there's several of these projects
going on as well). In the long run, you might find a market for
a music tool that is familiar to someone comfortable with the MPEG-4
methods of doing things.
- There is no proof-of-concept yet that shows that it is possible to
interpret SAOL quickly, unlike the others. I don't believe there's
any issues, but, well, show me the money.
- By working with SAOL, you show your support for standards in this arena,
and help to fight against the continued fractionation of the software-
synthesis world.
Please pose any questions on this topic you like; I'm committed to try to
answer them fairly.
Best,
-- Eric
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:23 EDT