I think it would generally be a good idea to make the results of commands like --status and --probe accessible from within ChucK in the future, maybe with extra information on what a shred's partents and childeren are (if any) and so on. Maybe something like a array returned by a function (something like " machine.shredList()" ?)that would list the active ID's and functions like " machine.childeren(shred-id)" that would return a array of a shred's childeren by id, "machine.sporkTime(shred-id)" and so on. The big question would be what to return if a shred has no childeren, it should be possible to do something to all of a shred's childeren provided it has any but I don't think zero length arrays are legal so I'm not sure what condition we'd test on in that case. Kas.

Spencer;

I agree that these features would be good ideas. (For the record size 0 arrays are legal/possible, and, predictably, doing anything other than .cap() will produce an array out-of-bounds exception.)

Great! (I missed that) So .cap() could be tested for and if it is larger then zero then the shred in question has childeren. That would be quite workable and intuitively sensible. Atte/all,

With regards to the wiki feature requests, let me say that you should definitely put feature requests on the wiki if you don't see them there already, in addition to mentioning them on the mailing list. For a developer thinking about new features it is a lot easier to look at the wiki page than to comb through the mailing list archives. Id say its disorganization is just a natural consequence of an "unmoderated" wiki; it is still fairly easy to read through despite this disorganization.

I understand and I just added this as well as a proposal for "modernising" the midi message structure that I already send to Ge. To clarify; I'm generally favour of debating ideas first before sending them in to the wiki since there might be better ones proposed after some talk or the whole thing might be unnesicary. The Wiki is great for making lists but not so great (IMHO) for talking about what should be on those lists. Unless somebody tells me otherwise I'm going to keep my hands off the "to-do" list entirerly because it would feel quite rude for me to tell you guys what to do but yes; before sending in requests it would be good to make sure they aren't already on that list. Yours, Kas.