Re: SAOL suggestions

From: Eric Scheirer (eds)
Date: Thu May 22 1997 - 09:51:02 EDT


In message <199705220532.BAA24179@brickbat9.mindspring.com>
Michael Gogins, he write:
>This is entirely feasible, but the faster you want the SAOL-compiler
>compiled code to run, the more work you will have to do on it.

Not me, I hope. Large companies with lots of money, technology,
programmers, and background in high-performance compilers, I hope. This
is the idea behind standards, anyway. And then the marketplace
does the rest.

>This may mean that there is no need at all for a complete low-level
>language compiler to implement a general-purpose, platform-independent
>structured audio language. Perhaps the only parser that is required is a
>recursive-descent parser for scores. People would write instrument
>definitions in Java itself using opcodes and other instruments supplied as
>Java Beans. Interfaces with native code implementations would serve as
>realtime audio drivers.

Lots of people are thinking about Java these days. There was a
lot of discussion about whether to build all of MPEG-4 around it. The
reason it was finally decided not to is that MPEG also has important
considerations in low-cost, reduced-functionality devices, and
standards which scale up as well as down are important. That is,
I could imagine building a "radio" device which implemented a
SAOL receiver/interpreter on a fast DSP and imbedded the whole thing
in a cheap portable box. I think this is much harder to do if
you have to build a conformant Java runtime package as well/instead.

As an analagous case, these days 3-D visual rendering add-on boards
are starting to take off in the PC world. Yes, you *could* do
the same thing in NSP on the CPU, but there's clear gains from adding
multiple more processors to the box. And you can't really do it
without an appropriate standard, in this case DirectX.

Still, the arguments from economy aren't exactly my favorite, and
in fact previous iterations of SAOL included extensive Java library
specification for user interaction and so forth. But we finally
decided that the MPEG opportunity was too good to pass up and that
we would make some short-term tradeoffs to meet the MPEG requirements.
(Check out http://www.headspace.com for some information on
potential upcoming java-sound standards.)

Thanks for your thoughts. I'd be interested, and I'm sure others
would be as well, if you posted to the list some of the interfaces
you designed for instrument design in Java.

 -- Eric

+-------------------+
| Eric Scheirer | A-7b5 D7b9 | G-7 C7 | Cb C-7b5 F7#9 | Bb | B-7 E7 |
| eds@media.mit.edu | < http://sound.media.mit.edu/~eds >
| 617 253 0112 | A A/G# F#-7 F#-/E | Eb-7b5 D7b5 | Db | C7b5 B7b5 | Bb |
+-------------------+



This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:11:08 EDT