[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.

-------------- 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