On 11/2/07, dan trueman <dtrueman@princeton.edu> wrote:

thanks for finding this; will be fixed next version.


Very good, thanks.
 

> When using the .rampDown() command, but then starting .play() again
> on the same voice before the rampDown has finished the rampDown
> will cut the new "note" off. This may be intended behavior? Giving
> a .rampUp(0::ms) when starting the new note avoids this situation
> so it's no real issue, just unexpected to me.

do you mean .play(1) cuts the new note off?


Well, no. It's a bit complicated, let me give you a timeline;

*note 1 starts on voice 0, in my case it's looping a small snippet of a larger buffer indefinately.

*note 1 starts ramping down and is thus scheduled to be turned off some time in the future.

*note2 on the same voice starts, using .play(1), cutting off the loop as note 2 is "one shot"

*the moment when note1 should've been turned off comes, had it not been for note 2. At this moment note2 is switched off before it finishes playing.

*here would be the moment where note 2 finishes playing when it reaches the end of the buffer, but it never gets this far.


I think the volume attunation of the ramp may also be applied to note2, I'm not sure, it wasn't very easy to hear. To be clear; I'm not sure this is a bug, perhaps it would actually be good to automatically fade out despite the voice getting all sorts of commands in the meantime but I think for looped files we can give all of those commands anyway and never need to supply it with a .play(1). My surprise comes from asuming .play(1) would "reset" any ramping that's being done, basically I expected .play to act like .rampUp(0::ms) does. Perhaps .play(1) is ignored when the voice is already playing? That would make sense.

 


of course, not sure why it isn't that way already!

Thanks! I think that's the last one that could get a meaningful "get" version, bringing it more in line with the other Ugens. I like this a lot, when you're used to "traditional" modulars polling Ugens for what they are doing is like pure bliss.


Thanks again for all your work and being so open to suggestions.


Yours,
Kas.