[chuck-users] MIDI channel / Interfaces / Machine.Remove /

Kassen signal.automatique at gmail.com
Sun Jun 17 10:41:38 EDT 2007

> Thanks, Kassen, for your reply.

You're welcome!

> Yes, sorry, my mistake - I meant device.

I suspected so, yes.

> It does and I probably wasn't clear. I'm curious to know if, when a shred
> terminates, there is a way for the application to be made aware of it.
> For example, there could be a onShredExit(Shred@ shred) callback function
> automatically called by ChucK just before the shred terminates whose content
> would be left at the discretion of the user so that for instance s/he could
> write some code to notify  all the objects dependant on this shred. But I
> guess there would be potential scope issues...

Yeah. What we do have is "Events". Events can be made a static part of
a public class and thus be system-wide. If you do that a shred that's
exiting could broadcast this event first, using it's own Id as a
parameter. Other shreds might then mourn the loss of their friend (or
squable over who gets the poor shred's room). Events are very usefull,
I think they could fill the functionality you are after.

> What about functors or some sort of pointers to functions and member
> functions? Now, that would be really great!

I'm not sure what "functors" are but I'd like pointers to functions as
well, especially if I could have a array of functions for situations
where you are sure *somthing* needs to be executed but exactly what it
is depends on some parameter.

What you can do is make a whole bunch of classes, each containing just
one function (called "do" or something similar) and asign those to a
array. That would at least create this functionality, at the price of
being very roundabout and likely needing lots of comments to avoid
baffled looks and confusion. This would result in something like this;


Which should execute function number "n" as that would be the function
in the class asigned to position "n".


More information about the chuck-users mailing list