On 9/5/07, <b class="gmail_sendername">Arthur Clemens</b> <<a href="mailto:arthur@visiblearea.com">arthur@visiblearea.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
><br>> Ok, so the issue is that ChucK keeps running when Processing is<br>> killed? If that's a real problem you could try to make ChucK poll<br>> processing over OSC every second or so and if it isn't running
<br>> ChucK could send a system command to kill ChucK.<br><br>How would this work? Unfortunately there is no command 'Machine.kill<br>()'. 'Machine.crash()' is not so neat.</blockquote><div><br>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.
<br><br>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).<br><br>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.
<br><br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Also, I cannot use 'OscEvent oeAlive => now;' because that will wait
<br>for the message that will not arive anymore...</blockquote><div><br><br>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.
<br></div><br>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.<br><br>Hope that helps,<br>Kas.<br></div>