[chuck-users] more LiSa notes

[dan trueman]

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 at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users