Overloading outlets?

    Jan 06 2013 | 12:30 am
    Here is my current situation... I made a custom [monome] class (with inlets and outlets) which communicates with [serialosc] (a bpatcher provided by the monome folks to send messages to the device)...I did this because I don't know enough yet to implement sending OSC stuff within java.
    Now, I also made a separate [sequencer] class (with inlets and outlets) which needs to communicate with my [monome] class...simply importing the monome class won't work because the monome class sends very specific messages out of its outlets to communicate with [serialosc]...I want to keep that class generic (inlets/outlets) for future use, and don't want to have to have to rewrite the outlet code in my sequencer...
    I can't simply have a monome outlet on my sequencer, bcs the sequencer deals with NxM arrays, and if you send those out of an outlet they just come out as one long list (1D array) which can't be generically processed by [monome]...I need the dimensional structure of the matrix intact.
    So, my question is: Is there anyway, when importing my [monome] class into my [sequencer] class to have whatever the [monome] class would normally output out of its outlets if it were standalone, come out of my [sequencer] outlets? An overloading of outlets so to speak...
    How do people deal with this? Writing generic classes which could be used standalone (inlets/outlets), but also capable of being called by other classes and using THEIR outlets...
    I spent quite a while rewriting this hoping to make it as clear as possible. I hope it's not a dumb question :<
    Any help would be appreciated!
    - Marcos

    • Jan 06 2013 | 12:33 am
      I guess I could rewrite the [monome] class to return a String wherever it would normally send something out of an outlet...that wouldn't take that much work...still, more elegant solutions would be appreciated!
    • Jan 06 2013 | 10:16 am
      I'm not sure I understand the question, but here's a couple of general suggestions:
      - make the classes abstract, with virtual methods for doing output. A specific sub-class could do direct output via MaxObject; another might feed through some other object.
      - make the classes take an output interface as constructor argument, and do output through this, which can either be a wrapper on MaxObject or some other class.
      If you're assembling output for a monome, you might want to look at this:
      It's designed to be scripted from Python or Clojure but works fine from Java. I've implemented Zeroconf support recently to take the place of the explicit host, port and prefix arguments.