I think compiling to Java bytecode is a reasonable approach. So is compiling
to Java source code. In either case newer compilers would run somewhere
between 0.6 and 1.2 times as fast as C. But I suspect that Csound would
still be faster. In effect, Csound does compile to pcode and it has been
highly tuned to do so.
-----Original Message-----
From: Ross Bencina <rossb@audiomulch.com>
To: Eric Scheirer <eds@media.mit.edu>; Saol-dev <saol-dev@media.mit.edu>
Date: Saturday, June 26, 1999 11:41 AM
Subject: Re: introduction
>Thanks for the feedback Eric...
>
>Eric Scheirer writes:
>>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.
>
>
>One thing that occurred to me after I posted my initial message is that it
>might be possible to complie to Java byte code and use the JVM to run
>things... just an idea, but has anyone attempted this? I have the saolc
>source and will have a look at it this week.
>
>>An important issue here is that except for SAOL, the other three you
>>mention are languages *and* implementations.
>
>point taken.
>
>> - 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.
>
>I tend to side with James on this one (not that I am overly familiar with
>SC). One of my main criticisms of csound is that it draws a line in the
sand
>and says: "Beyond this level of musical/compositional structuring/control
>though shalt use external score generation or write a new opcode." IMHO
this
>is required to do most things with grains and/or notes in algorithmically
>derived music. Is there any way to spawn new notes in SAOL?
>
>> - SAOL is the easiest to read, IMHO.
>
>
>I agree.
>
>> - Csound has a very rich, complicated and, perhaps, unusual set of
>> built-in unit generators. Reimplementing all of them would be a
>> monumental task.
>
>
>It seems that the ability to define new opcodes within a SAOL orc goes some
>way to reducing the impact of this.
>
>Thanks Eric, next up I'll sift through the mailing list archive...
>
>Ross.
>
>
>
>
>
>
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:23 EDT