i get it now, and see why it's happening. i'll have to think about how to address that. it does make sense to turn off the ramping if a play msg has been received, to avoid confusing situations like this. at some point i'm going to bug you to add some example files to the LiSa wiki! ;--} i'm sure you've got some wicked stuff going.... y'all might as well know, that i've updated the documentation online and added a wiki page for sharing examples. BUT, some of the documentation and wiki examples include features and bug fixes that won't be available until the next release; sorry about that! http://chuck.cs.princeton.edu/doc/program/ugen_full.html#LiSa dt
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. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users