[chuck-users] Circular references in class definitions
Tom Lieber
tom at alltom.com
Thu Dec 2 04:39:19 EST 2010
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/
More information about the chuck-users
mailing list