unbind pattr without losing the value?


    Mar 18 2008 | 7:20 am
    I want to use a single user interface object to control multiple pattrs, but only one at a time. That means when I bindto a second pattr I have to unbind from the first one.
    It *almost* works exactly how I want it to, except when I unbind a pattr it immediately goes to 0 and messes up the state of my patch. I need the pattr to maintain it's value after I unbind. Is it possible?

    • Mar 18 2008 | 7:39 am
      Actually there is another problem. When I bindto a new pattr I want the UI object to change to reflect the pattr's value, not the other way around. It looks like what I need is backwards from how pattr works. I want to bind the UI object to a pattr, not a pattr to the UI object.
      Can I make this into a feature request? Hopefully it is not too far fetched. I think it would be an elegant mechanism for building user interfaces in Max.
      In the meantime I guess it's back to pattrforward/send/receive.
    • Mar 18 2008 | 10:21 pm
      isnt that what our friend Stefan tiedje was picking on Jeremy Bernstein with ? :)
      anyway here is a ( not so elegant ) work around for your previous question which i am sure you thought about as well :
      Quote: Adam Murray wrote on Tue, 18 March 2008 08:39
      ----------------------------------------------------
      > Actually there is another problem. When I bindto a new pattr I want the UI object to change to reflect the pattr's value, not the other way around. It looks like what I need is backwards from how pattr works. I want to bind the UI object to a pattr, not a pattr to the UI object.
      >
      > Can I make this into a feature request? Hopefully it is not too far fetched. I think it would be an elegant mechanism for building user interfaces in Max.
      >
      > In the meantime I guess it's back to pattrforward/send/receive.
      >
      >
      ----------------------------------------------------
    • Mar 19 2008 | 4:42 am
      Quote: (karrrlo) wrote on Tue, 18 March 2008 15:21
      ----------------------------------------------------
      > isnt that what our friend Stefan tiedje was picking on Jeremy Bernstein with ? :)
      It's related, but different. pattr's bindto feature is really sweet. Simple and no extraneous objects. With the mythical pattrbackward object, I'd have to do something like this:
      [pattrbackward] -> [prepend set] -> [pvar ui_object] -> [pattrforward]
      With a reverse bindo, I wouldn't need any of those objects. I would also be able to connect all my pattrs and UI objects from a dedicated initialization patch that uses a single pattrforward + scripting to hook up the entire GUI from afar. That would make my patches much cleaner.
      The feature request is also about the way I think of patch design. My pattrs represent the patcher state. The UI objects should connect into the state and update it as needed. Instead, it's like Max wants the UI to represent the state. I think it's counterintuitive. No object-oriented GUI systems I've worked on act that way, but we all knew Max is not OO.
      > anyway here is a ( not so elegant ) work around for your previous question which i am sure you thought about as well :
      Thanks for that. Unfortunately, the patch I posted was a bit misleading. My real patch has the UI and pattrs are in different subpatches. The goal is to avoid running cables between the UI binding code and the pattrs.
      After mulling this over for a day, I think this is the best solution:
    • Mar 19 2008 | 8:38 am
      >
      > The feature request is also about the way I think of patch design. My pattrs represent the patcher state. The UI objects should connect into the state and update it as needed. Instead, it's like Max wants the UI to represent the state. I think it's counterintuitive. No object-oriented GUI systems I've worked on act that way, but we all knew Max is not OO.
      isnt the state given by what you do with the UI though ?
      unless you do a combo of manipulations and automations, i can absolutely see your point, specially if you frequently switch between these two type of actions, which is one of the main problematics of "computer assisted music" : finding the appropriate equilibrium between automation/generation and manipulation
      >
      > After mulling this over for a day, I think this is the best solution:
      >
      very nice work around , it will be handy