coordinating rhythmic timing with unpredictable OSC events
Hello all! I'm quite new to ChucK, and I have a question concerning rhythmic timing. I've got a program that I'm working on that accepts OSC events being sent from a C++ application. Now, the program chugs along, it's quite rhytmic, and I'd like to trigger melodic shreds based on values sent through OSC. No problem doing that. My problem comes from the fact that the C++ app isn't in sync with the ChucK VM, so the times at which it chooses to send data are pretty much never in sync with everything else that's going on, so the melodic shred is triggered but is not lined up rhythmically with everything else that's going on. Is there any way to hack it so that it waits to add the shred until it's lined up with everything else (quantized, so to speak). I'm not sure if I'm properly expressing the problem, so let me know if there's some way I can further clarify. Thanks very much! -crwicks
On Thu, May 03, 2012 at 07:54:01AM -0700, [chriswicks] wrote:
Hello all! I'm quite new to ChucK, and I have a question concerning rhythmic timing.
Welcome!
Is there any way to hack it so that it waits to add the shred until it's lined up with everything else (quantized, so to speak). I'm not sure if I'm properly expressing the problem, so let me know if there's some way I can further clarify.
Yes, I see. In that case I'd structure the shred like this; -define UGens and other stuff you need -advance time for sync -some sort of loop or structure generating your melody So far you seem to be missing the 2nd point. What exactly this would be like depends on the structure, but the shred should wait for something like the start of the next bar, or some VM-wide event indicating a new section. A very simple example of a structure like that is the series of "otf_X.ck" files in your examples directory. Those will always sync, no matter at what time they enter the VM or in what order. It sounds a bit like you will need something a bit more advanced, but it's not clear to me yet how the other things you are currently running are syncing to each other so it's a bit hard to say how new stuff will sync to those. Yours, Kas.
I think your problem can be solved with a technique along the following trick : 60::second / bpm => dur tick; tick - (now % tick) => now; if you add this at the start of your script, it will wait just long enough to start on the next beat. that way, you can have several shreds in perfect timing, even though they are triggered from an external event. hope this helps ! tom On Thu, May 03, 2012 at 07:54:01AM -0700, [chriswicks] wrote:
Hello all! I'm quite new to ChucK, and I have a question concerning rhythmic timing. I've got a program that I'm working on that accepts OSC events being sent from a C++ application. Now, the program chugs along, it's quite rhytmic, and I'd like to trigger melodic shreds based on values sent through OSC. No problem doing that. My problem comes from the fact that the C++ app isn't in sync with the ChucK VM, so the times at which it chooses to send data are pretty much never in sync with everything else that's going on, so the melodic shred is triggered but is not lined up rhythmically with everything else that's going on.
Is there any way to hack it so that it waits to add the shred until it's lined up with everything else (quantized, so to speak). I'm not sure if I'm properly expressing the problem, so let me know if there's some way I can further clarify.
Thanks very much!
-crwicks
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On Thu, May 3, 2012 at 10:54 AM, [chriswicks]
Hello all! I'm quite new to ChucK, and I have a question concerning rhythmic timing. I've got a program that I'm working on that accepts OSC events being sent from a C++ application. Now, the program chugs along, it's quite rhytmic, and I'd like to trigger melodic shreds based on values sent through OSC. No problem doing that. My problem comes from the fact that the C++ app isn't in sync with the ChucK VM, so the times at which it chooses to send data are pretty much never in sync with everything else that's going on, so the melodic shred is triggered but is not lined up rhythmically with everything else that's going on.
Is there any way to hack it so that it waits to add the shred until it's lined up with everything else (quantized, so to speak). I'm not sure if I'm properly expressing the problem, so let me know if there's some way I can further clarify.
Simplest way is to prepend your shreds with synchronization code like this: second / 2 => dur beat; beat - (now % beat) => now; If your tempo varies, you might need an object that sends 'beat' events and you could wait to receive one of those at the start of the shred instead. -- Tom Lieber http://AllTom.com/ http://infinite-sketchpad.com/
All 3 replies were spot-on, thanks very much. Tom Lieber, your suggestion works perfectly for my application, verbatim. Thanks guys, this list is fantastic! Loving ChucK.
-crwicks
________________________________
From: Tom Lieber
Hello all! I'm quite new to ChucK, and I have a question concerning rhythmic timing. I've got a program that I'm working on that accepts OSC events being sent from a C++ application. Now, the program chugs along, it's quite rhytmic, and I'd like to trigger melodic shreds based on values sent through OSC. No problem doing that. My problem comes from the fact that the C++ app isn't in sync with the ChucK VM, so the times at which it chooses to send data are pretty much never in sync with everything else that's going on, so the melodic shred is triggered but is not lined up rhythmically with everything else that's going on.
Is there any way to hack it so that it waits to add the shred until it's lined up with everything else (quantized, so to speak). I'm not sure if I'm properly expressing the problem, so let me know if there's some way I can further clarify.
Simplest way is to prepend your shreds with synchronization code like this: second / 2 => dur beat; beat - (now % beat) => now; If your tempo varies, you might need an object that sends 'beat' events and you could wait to receive one of those at the start of the shred instead. -- Tom Lieber http://AllTom.com/ http://infinite-sketchpad.com/
Hi There,
Graham Coleman had this awesome class called TimeGrid… anyone know where
that's located anymore? I might be able to dig it up this weekend. It
encapsulated a lot of this kind of quantizing functionality in a neat way.
-Mike
http://michaelclemow.com
http://semiotech.org
On Thu, May 3, 2012 at 12:34 PM, [chriswicks]
All 3 replies were spot-on, thanks very much. Tom Lieber, your suggestion works perfectly for my application, verbatim. Thanks guys, this list is fantastic! Loving ChucK.
-crwicks
------------------------------ *From:* Tom Lieber
*To:* [chriswicks] ; ChucK Users Mailing List < chuck-users@lists.cs.princeton.edu> *Sent:* Thursday, May 3, 2012 11:08 AM *Subject:* Re: [chuck-users] coordinating rhythmic timing with unpredictable OSC events On Thu, May 3, 2012 at 10:54 AM, [chriswicks]
wrote: Hello all! I'm quite new to ChucK, and I have a question concerning rhythmic timing. I've got a program that I'm working on that accepts OSC events being sent from a C++ application. Now, the program chugs along, it's quite rhytmic, and I'd like to trigger melodic shreds based on values sent through OSC. No problem doing that. My problem comes from the fact that the C++ app isn't in sync with the ChucK VM, so the times at which it chooses to send data are pretty much never in sync with everything else that's going on, so the melodic shred is triggered but is not lined up rhythmically with everything else that's going on.
Is there any way to hack it so that it waits to add the shred until it's lined up with everything else (quantized, so to speak). I'm not sure if I'm properly expressing the problem, so let me know if there's some way I can further clarify.
Simplest way is to prepend your shreds with synchronization code like this:
second / 2 => dur beat; beat - (now % beat) => now;
If your tempo varies, you might need an object that sends 'beat' events and you could wait to receive one of those at the start of the shred instead.
-- Tom Lieber http://AllTom.com/ http://infinite-sketchpad.com/
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
participants (5)
-
[chriswicks]
-
Kassen
-
mike clemow
-
Tom Lieber
-
Tomtom