At 11:41 PM 5/17/00, Robin Davies wrote:
> > > [Robin writes]
> > >
> > > Sfx currently evaluates the sub-guard-rate expressions unconditionally.
> >
> > > [Giorgio writes]
> > >
> > > The k-rate expression, if it is broken into intermediate statements
> > > like in saint, generates a k-block inside the a-rate-guarded block.
> >
>I may be mistaken here. Giorgio was referring to expressions rather than
>statements, and particularly wrt/ expression that provide parameters to core
>opcodes that take k-rate or i-rate arguments within a-rate guarded
>expressions. The distinction between statements and expressions is an
>important one.
>
Just a few words to clarify how saint works, and to explain better my point:
ksig control;
asig a_mono;
if(control==1) {
a_mono = loscil(tbl, cpsmidi(note), cpsmidi(base), loop, len);
} else {
// something else
}
the saint compiler roughly generates the following byte-code:
k_reg1 = (control == 1);
if(k_reg1) {
i_reg1 = cpsmidi(note);
i_reg2 = cpsmidi(base);
a_reg1 = phasor...; // vectorial
a_mono = interp(t, a_reg1); // vectorial
} else {
etc...
the compiler checks for rate of the arguments, and that's ok. Then it checks for
rate of loscil and that's ok, so the assignment is legal in the guarded
block. Only, I have two hidden assignments that are not. Consider that cpsmidi,
as all pitch converters, are completely decomposed in elementary operators
in saint, so I have a considerable amount of i_code inside the guarded
block.
What happens now (I think :-)) is that the i-rate lines generate an i-block that
is executed at k-rate (since that sub-block is called at k=a-rate), but this should not be.
It is not difficult to rework the compiler to make the code executed unconditionally,
as in Sfx. It is also not difficult to uprate the statement at a-rate, but this is , imo,
contrary to any logic (at least to the logic of saint). Identifiers and numbers (and
registers in saint case) are "evaluated" as memory accesses, and then in the
end they are equivalent at any rate if they are at the right side of =
My point in the previous e-mail was simple: in my opinion it is semantically not
meaningful to have expressions at a slower rate in a-rate guarded blocks, but
at the same time it makes a lot of sense to have parameters, in if/while blocks or
UDOs, that can only be initialization or control ones.
Proposed solutions ? For if/while I can agree on unconditional execution, it makes
sense to me. For UDOs the issue is more subtle, I already hinted a possible solution
that we implemented in saint but this is not supposed to be the holy gospel, just I
inherited it from many core opcode descriptions ("at the first a-rate call", "has not a proper
representation of time, but shall infer it from the number of calls", etc.)
i-block: first a-rate (or k-rate) call.
k-block: first a-rate call of an a-cycle
a-block: as understood.
I hope this helps,
Giorgio (with a help from Claudio)
__________________________________________________________________
Giorgio ZOIA
Integrated Systems Laboratory - DE/LSI - 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 - 12:03:55 EST