On Sep 3, 2007, at 8:56 PM, Kassen wrote:
On 9/3/07, Arthur Clemens <arthur@visiblearea.com> wrote:
No, this is just because of the way applets are quit in Java. If 'chuck --kill' is sent the processed are killed normally, so ChucK behaves predictable
Ok, so the issue is that ChucK keeps running when Processing is killed? If that's a real problem you could try to make ChucK poll processing over OSC every second or so and if it isn't running ChucK could send a system command to kill ChucK.
I have to try this.
It would mean I have a message sent from Processing at least once in a while.
The public class not used in the demo, but I kept the file because that is the way I would ideally solve it.
That's what I suspected now.
<snip>
So even if '
fileplayer.ck' is called earlier, it is added last to the VM. First the
chuckdemo.ck files are run and they do not know any FilePlayer class at that time.
Note that the order varies at each run. Sometimes the FilePlayer class is added second or third, sometimes first.
I don't know if this is because of the way Java calls the processes, or if class initialization in ChucK happens after file processing.
This is very odd, I'm inclined to suspect Processing is sending the commands in the wrong order.
The commands are sent in the right order. But they are sent though Java processes, and I don't know how Java handles these calls.
What you could do is start ChucK using this;
chuck --loop
fileplayer.ckThat should force it to be added at the right moment.
This works. But this is not a flexible solution from a Processing user point of view. I would prefer to use a generic setup.
Arthur