[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