Luigi Castelli

I wanted to share a simple patch with all of you, which shows that [pattrstorage] doesn’t do very well with dictionaries. Dictionaries are the only way in Max to build hierarchical data structures. so I love them and use them all over the place. However [pattrstorage] doesn’t dump out dictionaries correctly in response to the ‘dump’ message, nor retrieves them correctly in response to the ‘getstoredvalue’ message.

Is that a known bug/limitation of [pattrstorage]? Any way around it?

If I connect a [pattr] object to a dictionary the dictionary gets stored and recalled correctly. However it cannot be interpolated. Even though I see how this stems from the type of entity that a dictionary is, it would be very nice to be able to interpolate hierarchical presets saved in dictionaries for example and more generally dictionaries as hierarchical data structures.

pattrstorage_with_dictionaries.maxpat

I wanted to share a simple patch with all of you, which shows that [pattrstorage] doesn’t do very well with dictionaries. Dictionaries are the only way in Max to build hierarchical data structures. so I love them and use them all over the place. However [pattrstorage] doesn’t dump out dictionaries correctly in response to the ‘dump’ message, nor retrieves them correctly in response to the ‘getstoredvalue’ message.
Is that a known bug/limitation of [pattrstorage]? Any way around it?

Hi folks,
I wanted to share a simple patch with all of you, which shows that [pattrstorage] doesn’t do very well with dictionaries. Dictiona

storing-and-recalling-dictionaries-with-pattrstorage

Would like to second Luigi's observation/request.. seems a shame pattrstorage and dict can't be better integrated without having to resort to javascript

adding a third voice in support of the observation/request: developing within the environment would gain more intuitive ease if this were integrated according to Luigi's request.

im not against the idea at all but i think its good to note that the pattr system is focused largely on storing the state of UI objects and just arbitrary clumps of data, and that dictionaries have their own data storage mechanism already. similarly, pattr doesnt store col format data etc.

I don't really understand what you mean...

Dictionaries are general enough to be seen as "arbitrary clumps of data" as well. Dictionaries are "arbitrary clumps of data that could also be organized hierarchically" very similar to what Pattr is supposed to deal with. I also don't think that Pattr is focused on UI objects. It just so happens than many times UI objects are the ones whose state needs to be stored and recalled, but I believe Pattr is designed to be a general method to store any kind of data in a patcher. Also, as far as I know dictionaries do not have a data storage mechanism. For storage they employ the same format that Pattr also uses (JSON).

[coll] is a less general and structured way of storing data. Significantly inferior to [dict] in my opinion. Its internal structure is based on a linked-list implementation. Its hierarchical features are very limited and as far as I am concerned the only reason why [coll] exists is for backwards compatibility. With the introduction of dictionaries in Max 6 there is not really much use for the [coll] object. Everything you can accomplish with [coll] you can also accomplish with [dict].

I really can't see a reason why Pattr shouldn't be able to deal with dictionaries, including interpolating them.

@Nick:
I don't really understand what you mean...

Dictionaries are general enough to be seen as "arbitrary clumps of data" as well. Dictionaries are "arbitrary clumps of data that could also be organized hierarchically" very similar to what Pattr is supposed to deal with. I also don't think that Pattr is focused on UI objects. It just so happens than many times UI objects are the ones whose state needs to be stored and recalled, but I believe Pattr is designed to be a general method to store any kind of data in a patcher. Also, as far as I know dictionaries do not have a data storage mechanism. For storage they employ the same format that Pattr also uses (JSON).

[coll] is a less general and structured way of storing data. Significantly inferior to [dict] in my opinion. Its internal structure is based on a linked-list implementation. Its hierarchical features are very limited and as far as I am concerned the only reason why [coll] exists is for backwards compatibility. With the introduction of dictionaries in Max 6 there is not really much use for the [coll] object. Everything you can accomplish with [coll] you can also accomplish with [dict].

I really can't see a reason why Pattr shouldn't be able to deal with dictionaries, including interpolating them.

I think you're right Luigi, I checked the docs https://docs.cycling74.com/max8/tutorials/pattrchapter01 and it says-

So i'd guess that would mean dictionary data as well. I was probably getting confused in my mind with the preset object which does specifically call out being UI-object specific.

I think you're right Luigi, I checked the docs https://docs.cycling74.com/max8/tutorials/pattrchapter01 and it says- 


We can store any type of data used by any type of object (including data simply stored inside a pattr itself, without any other objects involved).

So i'd guess that would mean dictionary data as well.  I was probably getting confused in my mind with the preset object which does specifically call out being UI-object specific. 

Yes to being able to store and recall dictionaries. And an editable dict.view.

@luigi: dump is actually working -- internally, pattrstorage maintains a copy of the dictionary, and the name of that internal dict is output in response to a dump message: "a dictionary u809000846_a" for instance. If you were to create a [dict u809000846_a] object, you can view the contents of that dict and see that it's whatever is in 'a'. 'getstoredvalue' needs to be fixed, though, thank you.

Or are you seeing something else in response to dump?

As for all of the FRs here (interpolation, in particular), noted. I'd have nothing against a generic [dict.interp] object with some sort of pattrstorage-internal integration. Obviously, there are plenty of potential pitfalls there, but the ideal case of 2 identically structured dictionaries would be reasonably simple to build.

The dump message is interesting. The 'dump' message seems to output all dictionaries saved in pattr correctly. However, upon closer inspection, it always outputs the same dictionary appending a different letter to it (a, b, c, d... ) 

Also, the dictionary output by [pattrstorage] in response to the 'dump' message is unrelated to any dictionaries actually existing in the patcher.

Play with my example patch to see what I mean.

Yes, the solution you mentioned is exactly what I have ended up implementing for my own internal usage. I wrote a [dict.blend] object which is able to interpolate between two identical dictionaries. Not too difficult to code and works reasonably well. It also allows for recursion, so that if you have dictionaries of dictionaries those will also get interpolated. I am willing to share the code if you feel it's gonna help in any way, shape or form.

If there is interest, I could also attach the [dict.blend] object for download so that other people could take it for a spin and give their feedback.

Hi Jeremy, thanks for chiming in...

The dump message is interesting. The 'dump' message seems to output all dictionaries saved in pattr correctly. However, upon closer inspection, it always outputs the same dictionary appending a different letter to it (a, b, c, d... ) 
Also, the dictionary output by [pattrstorage] in response to the 'dump' message is unrelated to any dictionaries actually existing in the patcher.
Play with my example patch to see what I mean.

Yes, the solution you mentioned is exactly what I have ended up implementing for my own internal usage. I wrote a [dict.blend] object which is able to interpolate between two identical dictionaries. Not too difficult to code and works reasonably well. It also allows for recursion, so that if you have dictionaries of dictionaries those will also get interpolated. I am willing to share the code if you feel it's gonna help in any way, shape or form. 

Yes, that's correct, both your observation and the behavior. As I mentioned above, pattrstorage outputs _a copy_ of the dictionary, not the original dictionary. This is done to avoid sending direct references to the data in other objects out into the patcher -- we assume that the original data is 'const', so to speak and make a copy so that you can work with it without causing side effects. I fixed 'getstoredvalue' to do the same for some release in the future.

Hey Luigi! I’d like to better understand and implement hierarchical structures.

If you still feel like sharing your abstractions/objects I believe it could be nice to investigate possible applications and usability of such mechanisms.

 Hey Luigi! I’d like to better understand and implement hierarchical structures.

I don't have any abstractions/objects that are ready for public consumption at this time.

Hi Riccardo,
I don't have any abstractions/objects that are ready for public consumption at this time.
Thanks for your interest anyway.

hey, this is the most active and latest pattrstorage thread and maybe dicts could also have a nice solution for me.

I´m looking for solutions to edit data of a preset slot while slots of the pattrstorage are randomly recalled. 

to store a value to a client, I dont know any other solution as putting the wanted value inside of the client obj which is bind to a pattr obj, which connects the client to the pattrstorage. 

here is how I do it right now but I´m not sure if theres a better way... feels hacky..

I´m looking for solutions to edit data of a preset slot while slots of the pattrstorage are randomly recalled. 
to store a value to a client, I dont know any other solution as putting the wanted value inside of the client obj which is bind to a pattr obj, which connects the client to the pattrstorage. 
or is the another way to set a value?

here is how I do it right now but I´m not sure if theres a better way... feels hacky.. 

@tillfly: did you come further with this? 

I've opened your patch and I'm not quite sure, whether I unterstand what you need, but it sounds like smth I'm also interested in - also there is a constant error regarding the bindto occuring, is that part of your problem?

@tillfly: did you come further with this? 
I've opened your patch and I'm not quite sure, whether I unterstand what you need, but it sounds like smth I'm also interested in - also there is a constant error regarding the bindto occuring, is that part of your problem?

Hi Luigi, I use  interpolation with pattrstorage but I am stuck with using a huge amount of UI object to store my values since dictionaries do not support interpolation. Did you find a solution since you posted this thread ?

I'd really suggest using Emmanual Jordans approach to interpolate lists here: (scroll a bit down, he uses a simple vexpr to achieve interpolation, which is as sick as it is elegant!)

https://cycling74.com/forums/interpolating-between-two-function-tables#reply-58ed2036b7244922ce25e3f5

You still could use a dictionary / coll system to store different states. 

Depends on what you do, but I basically turned my back on pattrstorage completely since I've found that approach. 

Storing and recalling dictionaries with [pattrstorage]