At 12:56 PM 2/11/99 -0500, Eric Scheirer wrote:
>Hi Giorgio,
>
>I think you can do this just by keeping a global
>counter to keep track of how many notes have turned
>on.
>
>You can't control what order are executed in, but the
>k-rate passes are executed sequentially, not in parallel.
>The exports to the global ksig don't happen "all at once",
>they each happen when the instance completes its k-cycle.
>
>So this:
>
>global {
> ksig notes[10], count;
>}
>
>instr foo(pitch) {
> imports exports ksig notes[10], count;
>
> if (!itime) {
> if (!found(notes,count,pitch)) {
> notes[count] = pitch;
> count = count + 1;
> }
> else { turnoff; }
> }
>
>}
>
>kopcode found(array,len,x) {
> // return 1 iff x in array[0..len-1]
> ...
>}
>
>should work, I think. Have you tried something like this?
>Is this what you're asking for? Is there text in the
>standard that contradicts what I argued above?
>
>Best,
>
> -- Eric
>
Hi Eric and all,
the first solution I tried was actually very similar to what you
propose, i.e.
global {
ksig last[128];
}
instr my_instr(note, amp) {
ksig i_am_last;
imports exports ksig last[128];
if(!itime) {
i_am_last = !(last[note]);
last[note] = !(last[note]); // i am the last instance of that note
}
if(i_am_last != last[note]) { // another instance started
// goto decay and then turnoff
}
...
}
It seems to me that your array is very similar in behavior to mine. I am
working
at the moment with a piano classical score; because of sustain it reaches
in some beats
a polyphony of more than 40; if I am able to stop multiple instances of the
same
chords I will be able to go down to 25 more or less, that means near the
half of
computation required, for some seconds along the score. Moreover, this is
useful
if I want to describe the attack in a different way when the string or
whatever is already
in vibration, a common thing in many instruments.
About the standard, my problem is exactly this "all at once". The standard
talks of
end of the control pass, not saying if instance, instr or orchestra. If I
want a "causal" system
to be normative, the exports should be all at once; a solution could be
then to have
a "server" instrument, the only one allowed to export to last[ ], which
receives a control
score line for each new instance, while my_instr only imports; but again I
have my
second problem of "memory" for control statements on a "note" variable. I
could use an
array, and reset it after use, like that
1.00 control note[0] = n1
1.00 control note[1] = n2
1.00 control note[2] = n3 , etc...
and in
serv_instr() {
imports note[10];
if(note[0]) {
last[note[0]] = !last[note[0]]
note[0] = 0;
}
etc...
}
but I am not sure, in my understanding an imports-only ksig is a read-only.
Moreover,
is it easy to understand at the score level when notes belong to the same
kcycle ?
Again, this "all at once" is not only a problem of causality or not, it is,
more concretely,
the problem of what happens if some instances are running in parallel e.g.
in a SIMD
architecture. All the instances running in parallel will read the global
variables at the same
time and will exports at the same time (more or less).
If this is the situation and I see it correctly, I can imagine some
solutions. In my first attempt
I'd need an explicit exports as statement for a single element (i.e.
exports(last[note]) ).
The second, that I'd prefer, can be to make the imports from score without
memory,
that means that the variable is automatically reset after use. In such way
I could have my
note[10], without "writing" it explicitely. If I need a value to be static
I save it. Best of all
if the array can be addressed from the score with or without index: in this
second case
the value is set in the first non-zero location. I repeat, this only for
local ksig not being
global. But I see anyway that this is a little bit in contrast with the
general structure of SA.
A third last solution could be to make normative a sequential non-causal
system, but
I fear that in this way one of the best sources of parallelism in SA will
be destroyed. If so,
it should be better stated, anyway.
Does some other and better solution exist ? This is only what I see by
myself...
Best regards to all,
Giorgio
__________________________________________________________________
Giorgio ZOIA
Integrated Systems Center - DE/c3i - EPFL
CH-1015 Lausanne - SWITZERLAND
Phone: + 41 21 693 69 79 E-mail: Giorgio.Zoia@epfl.ch
Fax: +41 21 693 46 63
__________________________________________________________________
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 11:46:33 EST