>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.
I'm posting the final version of saolc early next week, Monday or Tuesday.
You might wait and grab that one instead.
>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?
Yes -- there's a command called "instr" that does this.
instr foo(p1, p2) {
ksig del;
if (p1 > p2) {
del = krand(1);
instr bar(del,p1,2,3);
} else {
instr baz(p2,-1,6);
}
output(agaussrand(p1,p2));
}
instr bar(p1,p2) { ... }
instr baz(q1) { ... }
The first two parameters to "instr" are the delay (so you can schedule
notes into the future) and the duration for the new note. The rest are
the p-fields for the new instrument.
You can see the sample "beat" instrument for a real composition (very
stupid one) that uses this function.
>It seems that the ability to define new opcodes within a SAOL orc goes some
>way to reducing the impact of this.
Yes, that's the point. Plus, the set of core opcodes is fixed within the
standard, so there's limited use to adding new ones to some particular
implementation (since the resulting orchestras won't run on other
implementations).
Best,
-- Eric
[PS - sorry for the bounces, those of you who are posting. I hadn't pruned
the list in a while, and will clean them up Monday if not sooner.]
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:23 EDT