[chuck-users] more LiSa notes

Kassen signal.automatique at gmail.com
Fri Nov 2 15:00:13 EDT 2007


On 11/2/07, dan trueman <dtrueman at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20071102/8ff98e43/attachment.htm 


More information about the chuck-users mailing list