Forums > MaxMSP

unbind pattr without losing the value?

March 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?

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P comment 125 196 42 196617 (unbind);
#P button 184 54 28 0;
#P button 121 57 28 0;
#P message 257 182 37 196617 bindto;
#P message 119 178 37 196617 bindto;
#P number 213 251 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 184 181 49 196617 bindto UI;
#P newex 213 228 40 196617 pattr;
#X prestore 1 0 0;
#P objectname u556000009;
#P number 93 252 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 47 181 49 196617 bindto UI;
#P number 47 57 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname UI;
#P newex 93 229 40 196617 pattr;
#X prestore 1 0 12;
#P objectname u137000007;
#P comment 26 58 19 196617 UI:;
#P comment 112 33 122 196617 Choose a pattr to control:;
#P window linecount 2;
#P comment 92 276 164 196617 Can I prevent the pattrs from going to 0 when switching the bindto?;
#P window linecount 1;
#P comment 261 200 42 196617 (unbind);
#P connect 14 0 11 0;
#P connect 14 0 9 0;
#P connect 13 0 6 0;
#P connect 13 0 12 0;
#P connect 12 0 8 0;
#P connect 11 0 4 0;
#P connect 9 0 8 0;
#P connect 8 0 10 0;
#P connect 4 0 7 0;
#P connect 6 0 4 0;
#P window clipboard copycount 16;


March 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.


March 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 :

#P window setfont "Sans Serif" 9.;
#P number 340 336 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 107 74 57 196617 r previous;
#P newex 75 420 27 196617 i;
#P newex 75 451 57 196617 s previous;
#P message 27 275 49 196617 bindto UI;
#P newex 27 245 58 196617 t b 1 b;
#P newex 92 346 40 196617 switch;
#P number 92 384 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 158 245 61 196617 t bindto b 2;
#P newex 183 328 27 196617 i;
#P comment 162 228 42 196617 (unbind);
#P button 244 114 28 0;
#P button 181 117 28 0;
#P message 413 248 37 196617 bindto;
#P message 340 247 49 196617 bindto UI;
#P newex 340 300 40 196617 pattr;
#X prestore 1 0 76;
#P objectname u100000057;
#P number 107 117 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname UI;
#P newex 107 300 40 196617 pattr;
#X prestore 1 0 0;
#P objectname u052000058;
#P comment 86 118 19 196617 UI:;
#P comment 172 93 122 196617 Choose a pattr to control:;
#P window linecount 2;
#P comment 527 385 164 196617 Can I prevent the pattrs from going to 0 when switching the bindto?;
#P window linecount 1;
#P comment 417 266 42 196617 (unbind);
#P connect 20 0 5 0;
#P connect 19 0 18 0;
#P connect 4 0 15 1;
#P fasten 4 0 12 1 112 322 205 322;
#P connect 6 0 21 0;
#P connect 9 0 16 0;
#P connect 9 0 8 0;
#P connect 16 2 19 0;
#P connect 16 1 15 0;
#P connect 16 0 17 0;
#P connect 14 0 19 1;
#P connect 12 0 15 2;
#P connect 10 0 13 0;
#P connect 10 0 7 0;
#P fasten 17 0 4 0 32 295 112 295;
#P connect 13 2 15 0;
#P connect 13 0 4 0;
#P connect 13 1 12 0;
#P connect 15 0 14 0;
#P connect 7 0 6 0;
#P connect 8 0 6 0;
#P window clipboard copycount 22;

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.
>
>
—————————————————-


March 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:

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 219 58 46 196617 bindto B;
#P message 135 57 47 196617 bindto A;
#P newex 198 117 62 196617 prepend set;
#P newex 198 139 43 196617 pvar UI;
#P newex 198 94 70 196617 pattr UI-hook;
#X prestore 1 0 35;
#P objectname UI-hook;
#P number 479 106 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 479 83 76 196617 pattr @name B;
#X prestore 1 0 4;
#P objectname B;
#P number 359 107 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 47 57 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname UI;
#P newex 359 84 77 196617 pattr @name A;
#X prestore 1 0 35;
#P objectname A;
#P comment 26 58 19 196617 UI:;
#P connect 9 0 6 0;
#P connect 10 0 6 0;
#P fasten 7 0 6 0 203 163 191 163 191 87 203 87;
#P connect 8 0 7 0;
#P connect 6 0 8 0;
#P connect 4 0 5 0;
#P connect 1 0 3 0;
#P window clipboard copycount 11;


March 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


Viewing 5 posts - 1 through 5 (of 5 total)