At 09:13 PM 10/23/99 , John Lazzaro wrote:
>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.
Hi,
I personally agree with John's comments and interpretations, just a
couple of remarks to make things even clearer.
I am not an expert in orchestra implementations, but in my
understanding the note has a duration that is set by the score
(and then influenced by the tempo), and an extended part that is
normally used to design releases and this kind of stuff. Of course
it can be used for any kind of use you are able to imagine, but
essentially its semantics is an idea of "rigid" as a counterpart of
the "flexible" note instance, the mechanics-walls-etc. and the
human being (oops, philosophy again ?). In this sense I agree
with the 2-segment case B in Ross' e-mail, even if so far I have
seen only notes still without extension or in the extension segment.
If I remember well a clear understanding of how the standard
works can be found in saolc, saol_sched.c, scale_sched_events
function: saolc is not just *the first* implementation, it is the
reference software, and in this sense it has the same value
of the text for every part that is normative.
>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
Unfortunately you are right, and opcode calls like that are
quite common...:-((
Regards to all,
Giorgio
__________________________________________________________________
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 - 11:46:35 EST