On 18 August 2012 19:47, Bastian Schumacher
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.