Bindto pattrstorage slot number?


    Mar 14 2008 | 5:32 am
    I am reworking a patch to separate the logic and the UI with the pattr system. So far it is working out really well.
    I am controlling pattrstorage remotely from my UI patch via a pattrforward. That works fine. But I'm stuck on one detail: I have a pattrstorage hierarchy and the top-level pattrstorage will change the slot numbers of my lower-level pattrstorages. I need my UI objects to update to reflect the active slot numbers. The problem is I can't seem to get the current slot number through the pattr system. For example, I can't access anything about a pattrstorage object through a pattrhub. I guess this is because you can't bindto a pattrstorage.
    Are there any tricks to make this happen? Or am I going to have to either
    (A) introduce an additional pattr to store the slot number, and bindto that.
    or
    (B) Do some scripting with forward and receive objects to communicate the slot number back to my UI patch?

    • Mar 14 2008 | 7:26 pm
      You can bind to pattrstorage with a pattr object, or an autopattr object. The pattrhub object, however, doesn't see pattrstorage objects. I would probably use pattrforward, the 'getcurrent' message to pattrstorage, route and a send to get that information as necessary, but your needs may require the use of other object types.
      jb
    • Mar 15 2008 | 12:49 am
      Quote: Jeremy Bernstein wrote on Fri, 14 March 2008 12:26
      ----------------------------------------------------
      > You can bind to pattrstorage with a pattr object
      Yes, although when I interact with the pattrstorage I see
      "warning: method getname called on invalid object" in the max window. Seems harmless?
      I'd prefer to use pattrs purely for state management and not communication...
      > I would probably use pattrforward, the 'getcurrent' message to pattrstorage, route and a send to get that information as necessary, but your needs may require the use of other object types.
      Sounds good. Actually [route recall] -> [send] should work fine for me. Usually I avoid send/receive but it seems like the best option here (at least until a certain oo library comes out).
      Thanks for the response.