[chuck-users] ChucK and Processing

[Arthur Clemens]

I have solved 1 main problem: starting and stopping Chuck by  
Processing. I have created a 'monitor' chuck file that listens for  
incoming events and shuts down Chuck when it no longer receives any  
messages.

New demo + video:
http://visiblearea.com/blog/bin/view/VisibleArea/ 
ProcessingandChucKHelloWorlddemo

Arthur


On Sep 5, 2007, at 1:45 AM, Kassen wrote:

> On 9/5/07, Arthur Clemens <arthur at visiblearea.com> wrote:
> >
> > 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.
>
> How would this work? Unfortunately there is no command 'Machine.kill
> ()'. 'Machine.crash()' is not so neat.
>
> The easiest and safest way is probably to use the standard library  
> function that issues a call to the OS and have the OS execute  
> "chuck --kill". The advantage of this is that it will also work in  
> the case the VM is set to --loop.
>
> This would elimiate the need for the sugestion below since you  
> could have Processing ask ChucK to terminate directly (or more  
> precicely; have Processing ask ChucK to ask the OS to terminate  
> ChucK).
>
> That being said; now that I think about it I have no idea why there  
> is no Machine.kill() command. Considdering that defining public  
> classes will make changes to the VM that can't be undone from  
> within ChucK it would seem ballanced to be able to destroy the VM  
> from within ChucK without crashing.
>
>
>
> Also, I cannot use 'OscEvent oeAlive => now;' because that will wait
> for the message that will not arive anymore...
>
>
> Yes. True. A clean solution would be to have your OSC parsing  
> function  write "now" to a variable of type "time" named  
> "last_time_we_heard_from_processing" (or the like) every time a OSC  
> event comes in. Then you could have a function that would  
> periodically substract this from "now" and if the outcome is longer  
> then -say- ten seconds this shred would call for the destruction of  
> the VM. The exact tuning of this might need some care because  
> obviously we wouldn't want to accidentally destroy the VM (and we  
> don't want to wait more then we have to) but as a general principle  
> this seems like a good plan to me and it also deals with the chance  
> that processing would crash/get stuck. You might want to check / 
> examples/time/ for details on how variables of the type "time" work.
>
> Disclaimer; these sound like good plans to me but I don't think I  
> ever actually tried either. May catch fire, no waranties, no refunds.
>
> Hope that helps,
> Kas.
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

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