Storing and recalling dictionaries with [pattrstorage]


    Jun 08 2020 | 2:42 pm
    Hi folks,
    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.
    Any comments on that? Thanks.
    - Luigi

    • Oct 26 2020 | 4:55 pm
      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
    • Oct 26 2020 | 5:01 pm
      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.
    • Oct 26 2020 | 5:13 pm
      Thanks for your support guys...
    • Jan 20 2021 | 2:04 pm
      adding a 4th voice..
    • Jan 20 2021 | 5:07 pm
      And a 5th !
    • Jan 20 2021 | 5:52 pm
      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.
    • Jan 20 2021 | 9:45 pm
      @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.
    • Jan 20 2021 | 9:47 pm
      5th+1
    • Jan 20 2021 | 9:51 pm
      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.
    • Jan 21 2021 | 10:47 pm
      Yes to being able to store and recall dictionaries. And an editable dict.view.
    • Jan 22 2021 | 10:22 am
      @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.
    • Jan 22 2021 | 4:34 pm
      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.
      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.
      Let me know...
      - Luigi
    • Jan 22 2021 | 4:43 pm
      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.
    • May 17 2021 | 12:17 pm
      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.
      Cheers!
    • May 17 2021 | 1:36 pm
      Hi Riccardo, I don't have any abstractions/objects that are ready for public consumption at this time. Thanks for your interest anyway.
      - Luigi
    • May 22 2021 | 3:34 pm
      : )
    • Jul 21 2021 | 4:11 pm
      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. 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..