[chuck-users] ChucK and Processing

[Arthur Clemens]

On Sep 3, 2007, at 8:56 PM, Kassen wrote:

> On 9/3/07, Arthur Clemens <arthur at 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.ck
>
> That 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20070903/bfd778ba/attachment.htm