On 11/2/07, <b class="gmail_sendername">dan trueman</b> <<a href="mailto:dtrueman@princeton.edu">dtrueman@princeton.edu</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>thanks for finding this; will be fixed next version.</blockquote><div><br><br>Very good, thanks.<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> When using the .rampDown() command, but then starting .play() again<br>> on the same voice before the rampDown has finished the rampDown<br>> will cut the new "note" off. This may be intended behavior? Giving
<br>> a .rampUp(0::ms) when starting the new note avoids this situation<br>> so it's no real issue, just unexpected to me.<br><br>do you mean .play(1) cuts the new note off?</blockquote><div><br><br>Well, no. It's a bit complicated, let me give you a timeline;
<br><br>*note 1 starts on voice 0, in my case it's looping a small snippet of a larger buffer indefinately.<br><br>*note 1 starts ramping down and is thus scheduled to be turned off some time in the future.<br><br>*note2 on the same voice starts, using .play(1), cutting off the loop as note 2 is "one shot"
<br><br>*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.<br><br>*here would be the moment where note 2 finishes playing when it reaches the end of the buffer, but it never gets this far.
<br><br><br>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.
<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br>of course, not sure why it isn't that way already!</blockquote><div>
<br>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.
<br></div><br><br>Thanks again for all your work and being so open to suggestions.<br><br><br>Yours,<br>Kas.<br></div>