[chuck-users] Circular references in class definitions

[Jordan Orelli]

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 <jordanorelli at gmail.com>:
>> 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 at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users