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

In my live performance setup, I had the concept of an "active patch". I never directly killed the shred that ran the patch (except in emergencies), but rather sent it a "cease and desist" message via semaphore. The patch was then responsible for ramping down, gracefully fading out, deallocating resources and -- only after all that completed -- the patch would exit the loop that ran its shred. If I understand the original post, this is the effect you're looking for. I don't see a practical way to build that into the core of ChucK, but writing a couple of general classes make it easy to implement across different patches. Make sense? - Rob

On Sun, Aug 19, 2012 at 03:10:50AM +0200, Bastian Schumacher wrote:

Why shouldn't it be possible to write a class for the pre-planned part which you can use to include your live code and pass the parameters during runtime (directly after leaving the loop). At least this would be an adequate solution from the theoretic standpoint. One could use a key from the keyboard as trigger button and the code may alter the parameters of the exit code if the tail may vary. I don't see anything that chuck can do now that could not be done using that technique.

You are right, of course; all the features are there. Ideally we'd insert something like a ENvelope between the shred and the dac, then write our own code for hotkey-based launching and updating. Could be done -in theory- in a weekend, especially if we'd involve our favourite scriptable editor. My comment wasn't base don the theory, but on the fear that this would run into the issues the type-system has. I see no way around storing the shreds and the representation of the shred's audio output(s) in a array, then re-assigning to that as stuff gets updated and that is where, in my experience, so nasty bugs are hiding. You are totally right about the possibility feature-wise and I may well be wrong; maybe it'd all work without a hitch. Maybe I'm getting old; it's not very ChucKist to fear a few bugs. ;-) Yours, Kas.

On 19 August 2012 15:11, Scott Hewitt wrote:

I am very intrested in this as well once sketched a system which detected inactivity on shred output to trigger in action.

Also cool might be shreds that can check whether the file they came from was updated and if so machine.add() the new one and kill themselves. The advantage here would be that we could pick the method of them leaving the VM, for example using a fade-out or only restarting at a particular point in a repeating music structure. Just thinking out loud here. Kas.

On 19 August 2012 15:27, Scott Hewitt wrote:

When you say fadeout are you meaning very quick 10::ms or more musically creative length like a dim.?

Well, whatever is more suitable. I'm trying to work towards more fluid updating of shreds, with a minimum of (unpleasant) artefacts. That might work in a slightly different way for different applications. Just getting rid of a "click" might be easier than full on 16bars crossfading in a techno performance if we accept some hackishness, I'd personally prefer a open-ended general approach. Kas.