Yup, using events worked out. Thanks for that. In general, I guess the best strategy is to define an event, then define the child object class (e.g. the object type that is to be encapsulated), then defined the parent object class (e.g. the object type that does the encapsulation). Using the event system got me tripped up a little bit because I was signaling events multiple times without yielding, so I saw spotty results at first. It helped a lot to trace out each step of the communication with console messages that just say "send" "signal" and "receive", each one written out by the appropriate object, with a reference to its class name. -Jordan On Dec 2, 2010, at 4:39 AM, Tom Lieber wrote:

2010/12/1 Jordan Orelli :

...

in short: Is there any way to have two separate classes that reference one another in their definitions? I want objects of type A to encapsulate a collection of objects of type B, but for objects of type B to also be able to hold a reference to their containing object. Alternatively, I could use an event system where the child objects (class B) raise an event that the containing object (class A) listens to. I'm not entirely familiar with ChucK's event model yet, though.

Here's the full story of the problem: I'm currently working on an instrument for the Novation Launchpad using ChucK. The rest of my explanation assumes you have a basic familiarity of the layout and functionality of the Novation Launchpad. The way it's structured, I have one class called Launchpad that is responsible for all data and functionality common to an individual device. It contains a collection of 8 LPIs (Launchpad Instruments). At any given time, one LPI on the device is in focus; interaction with the main grid and rightmost column controls that LPI. The topmost row selects between the 8 LPIs. The Launchpad object's main jobs are to allow the user to switch focus between LPIs, and to observe MidiIn messages from the physical device. So the Launchpad class handles and routes incoming data. The LPIs are the actual synthesizers; they manage (most) outgoing data. The problem I'm faced with is that the individual LPIs don't have a reference to the Launchpad itself, so I'm having trouble tracking the state of the MIDI lights in ChucK. This is needed to reduce the number of MIDI messages that I send to the device; ultimately I want to prevent any MIDI message that would tell the device to turn off a light that's already off. These messages have been creating a bottleneck, and under certain circumstances introduce unacceptable delay. You can view the source, and if you have a Launchpad check it out and play with it here: https://github.com/jordanorelli/chuckpad

I think your proposal to use events sounds like the way to go (because the only ways I can think of to add circular references to public classes are really hacky). But ChucK's event system is really simple (as is its public class implementation, as you've found out ;p), and is really summed up in this simple example from the manual:

http://chuck.cs.princeton.edu/doc/language/event.html#extend

You might pass the MidiMsg objects via the event if you don't mind re-parsing the data1, or you could encapsulate the actions your own way. It doesn't feel like the best solution, though, so hopefully someone else on the list is more enlightened. :)

-- Tom Lieber http://AllTom.com/ _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users