mike; What I mean by that is my conception of a class library
comes from the Smalltalk-style library where everything builds on everything else. This is great in purely object-oriented languages, but not so much in Chuck.
I see what you mean. Still; I feel that things like musicians, instruments, notes, phrases, modular-synth modules all have some "object" properties and it can make a lot of sense to think about them in that way. I also feel these concepts can have varying relations to each other, that it can make sense to group them, order them, sort them, etc, and that we may well like to do those kinds of things to those kinds of objects on the fly. To me this seems like a natural idea musically and on a structural level. Right now it's not all that clear how we should do some of this (some of it on the other hand is quite clear... other things are simply hard). I don't think this is a dead end. Right now your choice to focus on a different perspective is probably a good one but I very much like the idea of "everything building on everything" and we could use more of that. Not to "write Smalltalk in ChucK" as that makes little sense, but if we have a running "musician" object that's in some way connected to a "instrument" object I want to be able to take it's instrument away and hand it a new one, I want to be able to hand it a new phrase, to group several such "musicians" into a new "band" datatype... Currently I can do basically all of that using things like public classes with static members, having VM-wide events through which a "musician" controls his/her "instrument", that way I can have a lot of OTF control... as long as I know ahead of time what kind of control I will want in the future. If I have created this whole structure and ChucKed a band to a "stage" object and I decide I want musicians to be able to tickle each other I have a problem. Right now the more we create a framework for future freedom the more we define what kind of change is possible due to the nature of classes and public ones not being changeable. Smalltalk aside I think many of the underlying desires behind your attempts here can and do make musical sense; why shouldn't we have the ability to easily make a list that contains notes, phrases and instrument changes (maybe tickles as well)? Speaking purely for myself I feel that anything that makes musical sense should be expressible in ChucK, preferably in terms that aren't much more complicated then the intended effect.... Admittedly this is dreaming about a perfect future bound to arrive somewhere after flying cars, true artificial intelligence and Duke Nukem Forever but in the meantime I don't think we should content ourselves with describing ChucK's nature as not being capable of some of these structures, more like we haven't yet found a way to include that kind of functionality into the rest. Ok, that became quite general and philosophical but I felt compelled to reply to that side to your post. I'll have a more practical and focussed look at your code in the morning. Cheers, Kas.