[chuck-users] ChucK and Processing
arthur at visiblearea.com
Sat Sep 8 18:40:10 EDT 2007
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
New demo + video:
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
> 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,
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the chuck-users