Writing presets of two pattrstorage contents into one file?

    Feb 10 2013 | 3:23 am
    Hello and please, does anybody know of some way, how to save union of two [pattrstorage] objects into one file + to be able to refresh them both from the one file?
    Why i need this: in my patch, there are two pattrstorage objects on the same level (using the subscriptionmode 1). One pattrstorage is full of presets (i use store 1-16 there) and another one is for things like SOLO/MUTE, which you want to save with the file, but you don't want these influenced when you switch (recall) patterns. I was hoping, that doing it this way would work, If i'll put another pattrstorage in a parent and set it to GREEDY. I tried that, but it doesn't work (shown in attached compressed patch). The greedy pattrstorage can see the other two pattrstorage objects and all the pattr objects, but as I'm sending the "store " messages only to the two non-greedy pattrstorages, it seems to be saved only in them and the greedy pattrstorage does write only "empty" XML files (the file has xml structure, but no data in it).
    Please help.
    Or even other ways of saving some preset-independent data with pattr-presets together in a single file are welcome...

    • Feb 10 2013 | 3:40 am
      One solution I can think of is moving the preset-dependent pattr objects into a separate subpatch and use loads of [send]/[receive] or [inlet]/[outlet] objects to get the data there and back. Then store/recall only that subpatch when working with presets. Seems do-able, but maybe I'm just missing some facts about the greedy pattrstorage and this can be done simply. hmmm
      (and perhaps it's worth mentioning that the patch is already quite huge, (>800 entries in the pattrstorages together) so the more elegant and tidy solution, the better... (for example, storing/recalling each pattr separately would work, but would be crazy thing to do))
    • Feb 11 2013 | 3:53 am
      Is there perhaps a way, how to have pattr objects in pattrstorage NOT organizes by patcher/subpatcher hierarchies, but organizes manually into some subgroups which I could then store and recall manually?
      (if not, then i'll probably have to destroy my hierarchy + turn my patch into a mess (putting pattr objects far away from the UI it controls) to be able to recall some UI elements but not others on the same patcher level)