Hi, List, Hi Dan! Some notes; When the length of the loop accidentally becomes 0 I got a extreme CPU load, one different from a loop that doesn't advance time, it seems, in that quiting ChucK wasn't easily done (it started "cleaning up", then got stuck) and required a kill through the task manager. I think I would suggest ignoring the command that creates this situation (either .loopStart(), or .loopEnd(), I suppose .loop() itself could also be the final straw ) and printing a warning about the situation as this situation results in a de-facto end of the VM. 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. I'm not sure whether this is on "the list" already but I'd also appreciate "get" method for the .rate(), that way we could get the rate, multiply it by some fraction and set it again, like we can with all other pitched Ugens. (of course this can already be done by defining a extra float that keeps track of it but this isn't so elegant). Yours, Kas.
When the length of the loop accidentally becomes 0 I got a extreme CPU load, one different from a loop that doesn't advance time, it seems, in that quiting ChucK wasn't easily done (it started "cleaning up", then got stuck) and required a kill through the task manager. I think I would suggest ignoring the command that creates this situation (either .loopStart(), or .loopEnd(), I suppose .loop () itself could also be the final straw ) and printing a warning about the situation as this situation results in a de-facto end of the VM.
thanks for finding this; will be fixed next version.
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?
I'm not sure whether this is on "the list" already but I'd also appreciate "get" method for the .rate(), that way we could get the rate, multiply it by some fraction and set it again, like we can with all other pitched Ugens. (of course this can already be done by defining a extra float that keeps track of it but this isn't so elegant).
of course, not sure why it isn't that way already! best. dan
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On 11/2/07, dan trueman
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.
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
On 11/2/07, 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.
One easy fix would perhaps be to have .play(1) be a front for .rampUp(0::ms), I think those are equivalent in many ways, except that the ramp will also set the ramp? 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....
Oh, yes, I'm quite happy :¬). The issue with my project is that it's written around a arcade joystick and two rather unusual Playstation controllers for a music game that have a half-octave keyboard and a scratch pad (!!!). Oh, and it interfaces a set of Nord Modular patches. Basically you wouldn't get much use out of it unless you would hunt down and get the same components. What I'd like to do is make a simplified version that's usable with just a joystick (and perhaps PC keyboard) to explain my way of "joystick sequencing", include some of the philosophy behind it and release that. This would bring the system-requirements down from "be Kassen" to "have a arcade-style joystick with a USB connection" which is a lot more reasonable. Right now my setup works quite well but there is no manual and reverse engineering it would be utter hell, I imagine, as it's written around the controllers and there is no graphical interface or feedback and 90% is very unconventional in approach. I didn't yet start on a accessible release because I don't want to do that without including *why* it works like it does and that will need some time to very calmly sit down and try to write clearly. Better for demo-ing LiSa speciffically would perhaps be a keyboard-based breakbeat cutter or something along those lines, let me think on this. Thanks! Kas. PS; for live joystick sequencing in very low lighting see; http://bottomfeeder.ca/top/vinger.3gp I fear most people will have to "save as" and have some sort of modern versatile player that can take this mobile-phone video format that I can't seem to manage to convert to something more sensible. It's a shame the light is so bad and so you can't really see much BUT the sequencer is 100% ChucK and the music is all live (no pre-prepared patterns, at times it shows). I cheated in that the bass and lead sounds come from the Nord Modular but at least they are ChucK-controlled.
participants (2)
-
dan trueman -
Kassen