Forums > MaxMSP

pattr/coll-based auto assign

March 2, 2009 | 3:03 am

I’ve been wanting to start working on an abstraction that will allow me to quickly map controls to my keyboard. When it takes in a bang, the next controller moved would be used as the coll index, and then the next named UI object that is moved would be stored in the coll. From then on, anytime I use the controller with an object associated in the coll, it would be forwarded on to the object.

I’m fairly new to Max, haven’t used pattr at all yet, and have very little experience with coll. does anyone have any helpful advice before I get started? or is this even possible?


March 2, 2009 | 5:02 am

Bryan Dodson wrote on Sun, 01 March 2009 21:03I’ve been wanting to start working on an abstraction that will allow me to quickly map controls to my keyboard. When it takes in a bang, the next controller moved would be used as the coll index, and then the next named UI object that is moved would be stored in the coll. From then on, anytime I use the controller with an object associated in the coll, it would be forwarded on to the object.

I’m fairly new to Max, haven’t used pattr at all yet, and have very little experience with coll. does anyone have any helpful advice before I get started? or is this even possible?

I think the way you are envisioning it would be a bit tricky. You’d need a [change] after each any every possible controllable UI object to see "the next one that is moved", then store that info in the coll, and then reference the coll data (where it goes) to be routed back to the UI element. Doable but possibly overcomplicated.

If you hardwire your ctlin info this is the easiest but there’s no flexibility. So you might look into [select] which can have a single argument that can be changed on the fly. So, for each UI to be controlled, there’s a [gate] that’s only open when you’re in "learn" mode. Once there’s a value in (the controller number) it gets set as the [select] value. Then the UI element is tied to that controller. To manage controllers that have the same number but a different channel number, like [ctlin 7 1] [ctlin 7 2] etc., as select only deals with single numbers, use [match].

– Pasted Max Patch, click to expand. –

March 2, 2009 | 5:17 am

is there no object that can listen for changes in any [pattr]? that’s kind of what I was counting on…


March 2, 2009 | 9:23 am

Bryan Dodson wrote on Sun, 01 March 2009 22:17is there no object that can listen for changes in any [pattr]? that’s kind of what I was counting on…

For this I’d use the @outputmode argument in pattrstorage.

Here is a more complicated patch that stores pairs of CTL/UInames into coll. It’s not perfect (you might have unwanted messages coming out of pattrstorage, etc…) but it might give you some ideas.

– Pasted Max Patch, click to expand. –

Ciao


March 2, 2009 | 9:35 am

ah, yes! this is exactly what I was looking for, thank you very much.

Now that I have this, what would I need to change in order to make your patch function inside an abstraction (so that it listens for objects in the parent patch)?


March 2, 2009 | 9:54 am

Well, I would tweak it a bit more but if you keep all pattr-related objects *out* of the abstraction, you should be ready to go.

Ciao


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