pattrstorage ... how is this possible?

    Jun 17 2013 | 5:53 pm
    I give the pattrstorage a simple write order, which is then being confirmed by its outlet. But when I reopen the session, I get not the values that I saved last time but different ones. During boot up the pattrstorage is connected to a print object, so I would know, if it would get any write messages at that time ... how is that possible?

    • Jun 17 2013 | 10:27 pm
      When you say "I get not the values that I saved last time but different ones," do you mean "not the pattr values that were in existence at the moment I saved the patch", or "not the pattr values that I stored in pattrstorage (with a store message) and wrote to a file (with a write message)"?
      The pattr objects themselves will restore the values they contained when the patch was saved, independent of the pattrstorage object. If you want your pattr objects to hold values that were stored in a preset of the pattrstorage object (and written to the associated JSON file), you need to recall that preset (with an int message to pattrstorage) just before you save the patch (or recall them from the pattrstorage preset when the patch is loaded).
    • Jun 18 2013 | 6:21 am
      I found the problem: Some pattr object inside of bpatchers renamed themselves after re-loading the whole patcher. The problem vanished by leaving out the patchers an giving the recallable uis a scripting name (using autopattr). Seems like this works way better than pattrobjects, especially when you need to set priorities. I would really like to know, why those pattrs changed their names. COuldn't find a reason for that in the forum. As long as the program was running they kept their names and everything was saved and ready to recall. That just threw me off ...