Hi Michael,

'saolc' meets all of your criteria except for real-time.  There is no
intrinsic reason why saolc couldn't be made real-time; it's just not
programmed well enough yet.  There's a project going on hosted
at EPFL (a Swiss university) to replace the saolc core with a
real-time SAOL synth.  Anyone who wants to help, I'm sure they'd
be glad for it and I can put you in touch.

In particular:

> Either licensed under the terms of the GNU General Public License with the
> explicit provision that music produced by the thing be saleable for profit,
> or inexpensive (less than about $500). I would prefer the GPL approach.

saolc and the EPFL modifications are both open-source freeware.

> The kernel of the SAOL compiler and runtime should be written in completely
> standard C or C++ so that it can be compiled and run on any machine with the
> appropriate C or C++ compiler without any changes in source code, except as
> to platform-specific MIDI and sound drivers, which should be located in
> separate, dynamically loaded modules.

saolc compiles without problem on Alpha, Linux, OS/2, SGI, and Solaris.  It
should build on Mac, too -- I don't think anyone's tried yet.  Note that MIDI
support is also required in the MPEG-4 specification, including streaming
MIDI data, Standard MIDI files, and DLS-2 wavetable support.  This is done
(well, will be in the April release) in saolc.

> Without ever ceasing to implement the MPEG-4 standard SAOL language, the
> SAOL kernel ought to be able to dynamically load, at run time, new opcodes
> and wavetable generators and install them into its symbol tables. This would
> make the system dynamically extensible. Plugin opcodes, in other words.

Dynamic extensions are part of the SAOL specification.  You can write new
opcodes, unit generators, and wavetable generators in SAOL and they are
linked with the core functionality at orchestra compile-time.  This has the
disadvantage of being slightly less efficient than native C extensions, but
the advantages of guaranteeing portability between SAOL playback devices
and much easier authoring.

With an implementation-language plugin system per your suggestion,
what do I do when sending my SAOL compositions to someone whose SAOL
is running on a vastly different sort of player?  (A set-top box, for example.)
In my view, it's much better for extensions to be coded in SAOL, rather
than having to hybridize SAOL and C++ in order to extend the language.

There's no theoretical reason why a good SAOL compiler shouldn't be able
to run SAOL extensions nearly as fast as C++ extensions -- this is a
compiler-technology issue, not a music issue.  I note also that there's
now serious attention to SAOL in compiler-research groups at several
universities, studying the issues involved in efficient compilation and
run-time systems for SAOL.

> The SAOL system should be, as Csound is, a runtime compiler. It should be
> possible to write SAOL code using a text editor or score generating program,
> then immediately hear the results without going through a round of C code
> compilation. It is very difficult to make MUSIC without being able to get
> really rapid feedback on instrument and DSP design.

I agree.  This is the paradigm taken by saolc.

> The SAOL kernel ought to be able to produce real-time audio output, or write
> a soundfile, or both at the same time.

saolc is "real-time in principle": if your orchestra is simple enough and your
machine fast enough, it generates real-time audio output.  It's only a matter
of efficiency right now.  It generates AIFF files as well.

saolc on my SGI Octane is roughly the speed of Csound on my old Decstation
3500: roughly a factor of 10 for the average orchestra.  So it's not wildly out 
of
realtime now for simple things, and I think it's a straightforward matter of
development attention to make it 5-10x faster.

I'm happy to act as a clearinghouse for improvements made by others
per the Linux model, although I don't have cycles to actively develop saolc
anymore after April.

Best,

 -- Eric