[Stk] Bug in ADSR.setAllTimes decay rate?

Zacko Belsch zackobelsch at gmail.com
Mon Jan 20 17:47:12 PST 2014


Perry, I think I've confused things for everybody.  Here's a recap.

- ADSR.setAllTimes effectively misinterprets the decay times.

- Correcting ADSR.setAllTimes is simple but changes the behavior of all
existing calls.

- With the correction, the resulting decay times will be what the caller
specifies but this is
different (usually) from current effective decay times.

- If that difference results in a perceptible audio difference, the calls
to ADSR.setAllTimes could be modified, changing the decay argument to match
the "incorrect" decay time that ADSR has been producing.

- However, expecting that all existing calls to ADSR.setAllTimes from
outside the SDK would be modified is impractical.

I want to make it clear that as a total newbie to the SDK I'm not proposing
whether a change should be made or not.  It seems like a quandary from the
standpoint of backward compatibility.

Bob H
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ccrma-mail.stanford.edu/pipermail/stk/attachments/20140120/df94b67e/attachment.html 


More information about the Stk mailing list