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
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