> Hi, a couple of questions:
Here's how I interpeted these issues for sfront -- I believe it
is compliant given my reading of the spec, but it may be in
error:
-- Dur is in seconds
-- If a SASL or dynamic instrument command sets the note duration
to minus 1, or if the note is lauched via MIDI, the standard name
dur returns -1 forever, even after an extend or turnoff command
is executed in the instrument.
-- If a SASL or dynamic instrument command sets note duration to
something other than -1, then dur returns the sum of:
-- The time (in seconds) elapsed so far, plus
-- The time (in seconds) to go given the specified note duration,
after scaling by the current tempo (unless a turnoff command has
been executed) plus,
-- The time (in seconds) added or subtracted by aggregate extend
commands.
The current sfront (0.43) literally calculates this all out every
time dur is used, which is slow. However, the current internal
version (ready for the world in a few weeks) is smarter, and
pre-calculates dur at the start of k-passes for the instrument,
taking advantage of the the NOTES in 5.7.3.3.6 part 10 to get
around the worst-case issues involved in settempo() core opcode
calls.
In optimizing dur, the hardest issue sfront had to deal with was
that although dur is ivar, it has pseudo-ksig semantics, since
it value changes at k-rate if tempo is varied. This makes doing
rate-semantic optimization tricky. However, I think its important
to optimize it, since (for example) Giorgio's clari example he
posted a few months ago uses dur in situations like these:
asig aenv, ady, adyn, amod, a1;
aenv = iamp*oscil(ifenv, 1/dur, -1); // envelope
ady = ifq2*(imax-imin)*oscil(ifdyn, 1/dur, -1); // index
If expressions involving dur aren't properly factored out and
computer at k-rate, those are a lot of a-rate divides to do ...
--jl
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 11:46:35 EST