Re: [chuck-users] soft kill

Just piping in... I do think it would be useful and important to have a soft-kill button in the miniAudicle virtual machine monitor by default. Any system that involves running (and possibly writing in live performance) another Chuck shred just to kill another Chuck shred seems cumbersome to me. The button in the virtual machine monitor could talk to a special ShredEvent class, specific to each shred. A compile-time check could let Chuck now whether a given pile of code referenced that event or not. If it didn't then the - button could be the normal immediate de-scheduling. If it did, instead of doing the de-scheduling it could broadcast the message. The syntax might look like this then (: while(!Shred.rcvdStop) { // do something repeatedly } // make a graceful exit As a completely different point, in my own live coding and with the Cybernetic Orchestra I have often found it useful to sidestep this problem by tending towards code that doesn't loop indefinitely, but rather needs to be retriggered/re-sporked each time. Certainly keeps the fingers busy! Yours truly, David On 2012-08-18, at 5:47 PM, Kassen wrote:

On 18 August 2012 19:47, Bastian Schumacher wrote:

...

Hi Michael,

killing a thread means means immediate de-scheduling. There is not such a thing as "soft kill" in any software because the scheduler is not the place where that kind of functionality belongs to. What you want is a "quit"-mechanism for your program:

Yes, indeed. It'd need to be a static member of a public class, in practice; environment variable checking is too slow for this.

Sadly this means quite a bit of planning ahead, making it unsuitable for spontaneous improvisation. There has also been some talk about "crossfading" when replacing shreds; also a appealing idea if we ignore the CPU cost.

I think these are sufficiently sound and universal ideas to think about a framework/library for them. I'd like to help with something like that, but personally I'd like to first see a bit of the cleanup to the type system, particularly as it relates to arrays. I see no way of doing anything like this without arrays of UGens and assigning to those, combined with functions returning UGen references. There's a notorious amount of dragons there, currently.

Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-------------------------------------------------------------------------------- Dr. David Ogborn, Communication Studies & Multimedia, McMaster University Director, Cybernetic Orchestra & ESP Studio http://soundcloud.com/cyberneticorchestra http://esp.mcmaster.ca http://davidogborn.net http://twitter.com/ogbornd 1-905-525-9140 ext 27603