In addition to the ubiquity and the Java interface, another requirement of
mind is dynamically plugging-in opcodes.
In other words, I want to permanently bridge the gap between academic
computer music software and the world of commercial music software,
trackers, etc. If you guys make SAOL work as advertised, it will be roughly
equivalent in power to Csound, and if it had plugin opcodes experimental
composers and computer music researchers could add interesting new stuff to
a working framework/test bed and not have to rewrite all the input/output
code all the time; also their work would become more usable more quickly to
more musicians.
I don't think user-defined opcode macros are really up to this (but correct
me if I'm wrong; if the language is expressive enough and the compilers are
good enough, then I am wrong). I don't care about SAOL bitstreams ALWAYS
being playable by EVERY decoder as long as the plugins can be found
somewhere (see Buzz).
This plugin/framework architecture, of course, is becoming ubiquitous in
music and it is only a matter of time until we have some sort of really
adequate standard (or standards).
My motive here is musical. If some software synthesizer becomes standardized
at a powerful enough level, it will become something at which practice can
make perfect.
-----Original Message-----
From: John Lazzaro <lazzaro@CS.Berkeley.EDU>
To: gogins@nyc.pipeline.com <gogins@nyc.pipeline.com>
Cc: saol-dev@media.mit.edu <saol-dev@media.mit.edu>
Date: Thursday, July 01, 1999 10:21 PM
Subject: Re: SAOL Compiler
>> In this multiple-use, multiple-platform context it would actually be more
>> useful to have a SAOL compiler that produced machine-independent,
executable
>> pcode, something like what Csound does. Of course Csound is almost a
>> "little" language and that is why this approach is practical for Csound.
>
>I guess in the limit, I'm expecting to be able to find an MP4 Structured
>Audio decoder everywhere that I can find an "MP3 file" decoder today --
>which may be approaching JVMs in ubiquity at this point, given how
>many proprietary player programs are adding MP3 support.
>
>For your application, I guess the important question is "what's that limit,
>in terms of how many years away?". Anyone have a good crystal ball out
>there?
>
> --john lazzaro
>
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:24 EDT