Pattr and non-interface objects.
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?
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)."
"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.
doubleclick the pattrstorage object
----------begin_max5_patcher---------- 721.3ocyWssiaBCD8Y3qvhmSWAlag9V+NpVEY.u65JvNxX1l1U4eulwPhSBk PyRh5CADdrGOmybMe353kK1Qa7PeE8cjiyGtNNvRcK3z+siWMYWQEoA1lGm9 SQ9O7VYD8NQxI0TPRiRHIuRGDon6Tv5aIJkrWH5rM8hfqZX+FTPf+S98Kyaq Y7JpBtxf9EKDUBowTCz6D4e3g9SzyGOpnUc9Y01PwaL9qajzBkQG3f3tyF4C uB7MZZskpL5Q8qsTyI77NHhUBPSyDeIIzFLGXiuIYjpAIMj2okaz6Ve6a5nC Vdqxv6NG3YmAFzxHiWGtBkj0YegQ5mYoClPGljDMMwT0hR3N8GjTTwnbkkZz GMp6GVCwrrjyzAUQkanbRdkQMfr8ttCO26tZlAGEh5Z8MeQHfFqpQc43oc4m 5L8mvYFuFbe3vtWgfuD6a4KsbXX+IbX2.n0tRkf6MebLUPYXjENvWhiKhIyI 7WGMtLH8V.yoo2GygkzsTdI5EIs7y6Hmh.7y.BHqSgnzrqS.iC93k0GeEZIW HYM2WdICBLvo.urN5V4knGDuv322D9frDHSGadEMUBeP3xB5ZZSyXM55RNzE pWYBGPmVm4ZL.9eMhHJJ0.Z.6Yo2X6q.78Lhvd9.5NR81JJ.kK3NRqR.CJfF aa2dHTzTDHzy.GCgPAgIyHmZk0uwXyrqOKfj10lmddueSIj9ZfnmW9dvKTMp IaBaRCifIpFgOsHp0KaT2eCzKS+popCkX5Wk.spCClByoKblVacNUNVl1B4p wS0Nx2xUGOi4TfFBSLtR7ipLjcHwg3D1csTM1GaGjfeJdNr0nytNOVBNpWEi e9+sCLtt0Ok5ZDsxhg6t2afNZdk5RVLNQwzi4dbOcyRXso2XkkTtc5RMqbqP ijdavTT6B+3bMI7bLo3GpIoGw951D9wZRyxyE9Xson+Cso4DNk8ILI8G6c+C Ff8.c. -----------end_max5_patcher-----------
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.
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.
----------begin_max5_patcher---------- 544.3ocwUssaaCCC8YmuBA8blgkbhSxdq82XsHP1hKQC1RAxxcYqn+6Sh1NW V8RcSQ5dvVPjTTmygDTOOIhla1C0TxWIeiDE87jnHzTvPT29HZkXeQonFCiV Xpp.siNs0mC16P6rXRMnkjZSEPzMU4fk3LjcBmy9f9AM26W7DPD9XrPoQHIt sPvew1f+zXRtPugnztv41.NzesyXAYWB6uzRkFJLMZ7lm2YzGhRWBNDlrNie 2nc0peCnsj3jiwZZb8A2aEwhRuYsEJbsZBe9J+gHL9hvBmwCKYyhSHO1cHkD ouI+GeYN8jaUKpvakdmUIJI2aJkzf2WlLI7a5Hk67FmynoWhimSF1+lLrYos jYIRlj9+G3RaZb+ZGzd.ZnhPGhprjqgLUPcsXC7pdmECxO96oFdIZmlgLMkE VlizlkcIZOHkytAU2+SBxRVae.1amximeUBxraffnge5SceheRXOj2lzEqRR R37kuRsvYLzO7Xfz2VwxvkYX+Da4EUroceCob72R45baAb7WaJWbHSg4nx09 D4w25.2U9oDsSwiNnqAdX8o1A10fVjWhoIA8gEkOVo4f3qN9VvsoYMCG8xVk cRy5Ek9.hFbl06neEOO9Nye83Hhvf8yUpZSisnG.cCHmRNBRouRpzBmxOK+j fNKlsJoDzm9fTkRty3oSGFHONXYazPZDHxOjiv9zPzrQfH9mpFwGYU6Z0H+l Wl7G7PGN5A -----------end_max5_patcher-----------
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?
----------begin_max5_patcher---------- 934.3oc2YtsaZCCFG+5vSgUtlUEamCjc2dE1tbpBYRba8ThCJwzQW0d2mOAj U.iSKDP8BBJ1F6+922A+kvqSBBWzrl1EB9J3mfffWmDDnaR0Pf89fvZx5hJR mdXg7U0KnsgSMcIuiwqnBcevcM1rRroUjs0GZ3hN1en5QFcWjsYyHEurjZTQ HiKBmBBWP3OFBt2NpkDQwSL9iyaoEBy.gH4b.f3L0WwP8MytKZ6OgUp0ayhe 8EXTXOQvI050J7asLRUnpi+NYh5xTOYPQScMUISSeB5ZslB+NsfTUADOQAcB hfBZd.rnok0AH7RvCszxAvsH2b6.DAo6FfloQBLM0ESPvyKSpoccjGo6wDzA 2xnCtkgCzUwo+AJVSCrAJXzcIJlbDXfFGX.uZvHJ0eXfGmnkeHZZoWsfEHxD rfloiRRhbl.I+Sdvhc+iRfm1+.l8IOXABS8GFm4znb5ukS6drXYKcIUFVzoh YFPbwEgKY5PlLjqHlzyLVtUp5HNWi.r5p6bFwWRGimIsamRUpxxW5l+PKS5h ruqCQHZAGdPd.R7P8flZ+3t1MM.yzEpjm4L0qCLZ6okZBKLFn3syRG4YZ4b4 jHW24JJvVrRXp1MXKkU5qUNsBZ6bJmrnROOQ59zlnymgRoxCknSagrcBdyfJ ZpZZsPSgonsWf830UJS.NwjCHxYfPJ9zlPOMUEURuWQ+vQYo+pOHkeTd5lk+ HF0McZYbu4IYFdJHMWsWvx4Clm8lohwYh5lxOpywwpERtWEezxcPNK2IJdWh Kr4v9niT+Wzndj1.qzC5dqOL+XS1bXj4.sbWTAlLpTQWI70BKvHCWR0eMK1I WhGItv3W1HD6I6QI5HD26Y73TArJzPZLlZetncAlu2JheuNDnbMOrGaehCrQ iUgOz0j5kUTsd2icjUhFSoOGZXd3AEOT.N0yhe1.yDr4EXk5xUKePk+z+rRS FD8Jll.t+7el0PSQM7PxLCgh0UY3lSyFm2Yw430R39b5zcGEggt1wYWxmvpe X1PsynAF338K70dpjwcHwYMLIi4CesmWB6BlmVQqSWRi0AR+pKNZcd9wH8OM rhwe6+SfdwUs++fqqYUawF0ZWGvNATJyVw3DAqg2aLp2PeuA8Dqrjx6GAUyJ W1H26VMXxmsmUzWIk3ijhGUI4EkRFUIA8BS3wUSw2fZxGaW93JIOTD51y+dT UT7MGiR8PQoiruclOZZbkD7lSRH7smkCgtzZRdyem7O.oMIcMC -----------end_max5_patcher-----------
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