[chuck-users] Object reference weirdness

Kassen signal.automatique at gmail.com
Thu Sep 25 22:26:15 EDT 2008


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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20080926/ef2bf1ac/attachment.html>

More information about the chuck-users mailing list