Stephen Powell

Apologies if this has been adressed before, I couldn't find anything directly relating, although I'm sure someone must have wondered this before.

Pattr only seems to work with interface objects, as the help-file states. My performance patch is very very large and most of the workings are totally behind the scene and seperate from the user interface. To save CPU and sometimes space I have done my best not to use interface objects, such as replacing an integer box with the integer object. TO put interface objects to start using pattr would not only take a vast amount of time but would reduce the efficiency of the patch and would make a ridiculously large patch even larger (well over 100 abstractions, some in themselves quite large).

Is there any way to get pattr working with non-interface objects or is there another system that could help?

Apologies if this has been adressed before, I couldn't find anything directly relating, although I'm sure someone must have wondered this before. 

Pattr only seems to work with interface objects, as the help-file states. My performance patch is very very large and most of the workings are totally behind the scene and seperate from the user interface. To save CPU and sometimes space I have done my best not to use interface objects, such as replacing an integer box with the integer object. TO put interface objects to start using pattr would not only take a vast amount of time but would reduce the efficiency of the patch and would make a ridiculously large patch even larger (well over 100 abstractions, some in themselves quite large). 

pattr-and-non-interface-objects

I made a similar mistake some time ago, namely thinking that pattr is the appropriate tool for data storage. Use coll.

Pattr works for non-interface objects too. Quote from the help file:

"By default, the pattr object maintains its own data.

This data can be of any normal Max type (int, float, list, symbol)."

"By default, the pattr object maintains its own data.
This data can be of any normal Max type (int, float, list, symbol)."


"works" and "is useful/right for" are two very different things. Perfect example; I put autopattr in one of my patchers and max would autoclose it when I opened it; I had to go in and edit it by hand.

You can emulate the funcltons of various [zl]s with pak and unpak, but why would you?

Jamesson, I indeed use coll for data storage, but this is for patcher recall, unless I have misunderstood your post.

Broc, pattr does seem to maintain it's own data, but not communicate with non-interface objects. Example attached.

also non interface objects does not show up in pattrstorage object.

also non interface objects does not show up in pattrstorage object.
example:
doubleclick the pattrstorage object


Not to beat a dead horse, tsuki, but I think you are confused about what you mean by "patcher recall". All you need to do is parse the coll to send and recieve data the way you want, then load and save it. If you want to have the patcher automatically load some values, just loadbang a load message.

Alternately, if you think this data is not going to change (ie if you only have one set of values you need to load and not a bunch of differnet sets that you choose every time you load it) consider just using a bunch of int and float objects - simpler and more efficient.

To reiterate, I understand your thinking - I too recently sought to use pattr for that purpose. That's not what it's for. It's similar to the "presets" you see in vst synths that ship with DAWs. If you take a look at those you'll see that they don't interact with anything but ui objects either.

Not to beat a dead horse, tsuki, but I think you are confused about what you mean by "patcher recall". All you need to do is parse the coll to send and recieve data the way you want, then load and save it. If you want to have the patcher automatically load some values, just loadbang a load message. 

To reiterate, I understand your thinking - I too recently sought to use pattr for that purpose. That's not what it's for. It's similar to the "presets" you see in vst synths that ship with DAWs. If you take a  look at those you'll see that they don't interact with anything but ui objects either.


Ah Jamesson I see what you mean. I use coll for that purpose at the moment, in a different context. It just so happens at this point that the patch is so huge and so sprawling that associating various objects with pattr rather than building in a coll storage system would have been much less hassle. Sends and receives and different abstractions for sending and receiving already bulk out a considerable amount of the patch so something simple and elegant would have been preferable.

Thank you for your input, I will still consider that as an option as it seems that pattr is indeed restricted to interface objects.

Ah Jamesson I see what you mean. I use coll for that purpose at the moment, in a different context. It just so happens at this point that the patch is so huge and so sprawling that associating various objects with pattr rather than building in a coll storage system would have been much less hassle. Sends and receives and different abstractions for sending and receiving already bulk out a considerable amount of the patch so something simple and elegant would have been preferable. 

Thank you for your input, I will still consider that as an option as it seems that pattr is indeed restricted to interface objects.


Send, recieve, pack, and unpack make data routing a lot easier. The real work comes with formatting the coll. Consider dict if it helps.

As a _last resort_, insert nums and flonums wherever you need pattr connections.

This patch shows how pattr can be used with a non-interface int object.

This patch is a modification of the one Lee Wang posted, showing how to to 'hook up' a pattr object to a non-interface [i] object, giving pattrstorage the ability to see/manage that object.

Personally I find pattr + pattrstorage a much more manageable (and easy to scale + implement) method for patch (preset) management than using coll. Why write your own routines to store/recall/distribute patch-state data when pattrstorage has that functionality built in already?

http://mspcafe.g2312.de/tLb/framework/pattr/

indeed, anyone coming across this thread in the future must completely ignore all the pattr-bashing. people get scared off the pattr system, but the best thing to do is learn it and use it. it is powerful, and makes life in massive patchers a breeze. the idea of 'rolling your own' (especially in coll, which is really slow) is ridiculous. when you need to manage state for massive setups across multiple patch hierarchies and upwards of 800 data points including arrays, the thought of using anything other than pattr is the stuff of nightmares. i also use it for tiny simple one or two params usage as well. quick, easy, powerful. just go learn it. 2c.

How is it "bashing" to argue that certain objects should be used for certain things? What you guys are suggesting are kludges. If you say they are faster this may be true in terms of development, but in terms of performance using precompiled stuff in unintended ways may result in huge hits. I'm not saying that it does, I'm just saying that if you want to do that you should show that there are performance gains to be had. I mean, c74 isn't stupid. If they clearly made pattr to be used with ui objects, then why would we shoehorn it into generic data storage? Some basic thought about the way presets function in other apps will show that they are not really meant for "data" storage and routing.

oh dear, apologies, it seems i am becoming ever more 'troll-like' in my old age. i do not mean to be.

i mean whatever floats your boat, lets all just use the objects we like. just some of us will be right and some of us will be wrong (!).

for all i know i even misunderstood the thread.

Pid, after the stupidity of the help thread your classiness is truly a breath of fresh air. Would that I could get some takers for my call to arms in wikibuilding

Pattr and non-interface objects.