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 <bastian.schumacher@yahoo.de> 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, <ogbornd@mcmaster.ca>
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