[chuck-dev] Sporking til you drop (wake time is past, wake_time < (now_system - .5) )

[Andrew C. Smith]

No idea how that sent. Must have hit a hotkey.

It calls next_id() and add_ref(), and sets a couple of variables, then
makes sure that the timing matches up.

The weird part is that when I do this whole thing in the mini,
sporking one shred every 30::ms, there are no problems at all. I'm
editing buses, basically doing everything, just driven by oscillators
rather than by my orbiting circles, but it runs much more smoothly. Is
there a place in there where shreds can get hung up with timing? Is
sporking a child shred much less likely to cause the VM to lag than
chucking a fresh shred?

Pretty close to getting something cool working--orbiting circles
control delay lines, and if you set the orbit periods differently the
whole thing drifts in a weird phase. Hopefully turn into a cool toy,
or ChucK apps for the iPhone or something.

Andrew

On Sun, Oct 25, 2009 at 11:17 AM, Andrew C. Smith
<acsmith at willamette.edu> wrote:
> I've discovered a slightly strange bug, or possibly my computer is
> just running out of resources. I got chuck working as a dynamic
> library in an external program, and have circles orbiting around other
> circles sending the areas of all possible triangles made from the
> orbit points to global buses. Basically, this requires an update every
> frame tick, at 30::ms (arbitrary, judged by what frame rate looks
> adequate on most video games) and then one of my chuck files
> interpolates between the points at a control rate.
>
> I've gotten it down to where I just append "Bus.setChan(x, y); \n" to
> the end of a string (I use a method "setChan" so that it can broadcast
> an event to waiting shreds, rather than just having the receiving
> shreds update constantly) then right at the end of every frame tick
> (assuming that my string has contents) I spork the shred. This means
> that only ONE shred is sporked every tick, no matter the number of
> buses or global variables I've changed.
>
> The problem is that I consistently get this message: internal sanity
> check failed in shredule() / (wake time is past) - x : y (where x and
> y are numbers referring to time passed in the VM, I believe). I
> checked it out, and x is SET to y just two function calls earlier,
> with nothing much happening in between. It calls
>