Forums > MaxMSP

pattrstorage … how is this possible?

June 17, 2013 | 10:53 am

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?


June 17, 2013 | 3: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).


June 17, 2013 | 11:21 pm

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 …


Viewing 3 posts - 1 through 3 (of 3 total)