I am not sure myself how much I could contribute to a more efficient SAOLC,
since at this time my time goes mainly into composing, but I would certainly
appreciate your putting me in touch with the EPFL so that they and I could
determine that ourselves. I am currently working as a software engineer
doing C++ development for Infinity, making a foreign currency trading
system. One thing that springs to mind that I could do without much effort
is to provide a Java and/or COM interface for the thing. I might also be
able to help optimizing specific sections of code.

-----Original Message-----
From: Eric Scheirer 
To: 'Michael Gogins' ; Thomas Hudson
; Richard Dobson 
Cc: Larry Troxler ; Csound List 
Date: Sunday, February 28, 1999 1:14 PM
Subject: RE: if.../ Common Lisp Music / compilers / interpreters


>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
>