PattrStorage dropping data
I’m working on a standalone app that saves some userdata into a pattrstorage object. Upon load, it is supposed to autoload this data. Weird thing is, it sometimes will not load any settings when it gets reloaded. Most often, it’s after a complete reboot of the computer.
I’m wondering if I need to put a delay in the loadbang? Could the closebang be sending bad data since the app is closing? Or, it it a problem with my patching? Could it have to do with it being a bpatcher inside of another patch?
Here’s the patch, I’ve removed as much of the excess logic and stuff as I could, while still keeping the need-to-know intact.
I’m having the same problem, and I’m doing this a similar way. I suspect that when I change and re-save a subpatch, some data gets reset to whatever I had in the pattr aware objects. If I fail to reload the saved setting, they get clobbered when I close the main patch.
I am also saving a bunch of MTRs and they get overwritten by blank ones sometimes too. Other than creating backups of the folder where my settings go, I haven’t found a way to avoid this yet. I hope that once I’m done making changes, this will settle down.
MH
I’ve done some experimentation, and it appears that the stored .xml file keeps it’s data after reboot. The data listed is all correct from the last load.
However, the app seems to ignore this data when it re-loads, even though it is executing the re-load section of the patch. This does not happen if I simply quit out of the app and then reload it without rebooting the computer.
Good grief – so it’s not just me! I’ve been tearing my hair out today trying to figure out why settings that I can see in the XML file aren’t being recalled properly. It’s umenus in bpatchers that 8′m having this issue with – and it’s not every instance of a particular bpatcher, but it is the same particular instances every time.
There are 4 sample players, where the samples are dynamically loaded depending on an overall scene that is selected at higher level of the programme. When a scene loads, the relevant audio files are loaded from disc, and their names put into a umenu. The required umenu slot is stored in pattrstorage. Each player is an instance of the same patcher, yet the umenus in each don’t respond the same way to having a preset recalled. Players 3 & 4 will be recalled correctly, but maybe 1 or 2 won’t.
What’s really strange is that I’m reasonably sure that this wasn’t happening a week or so back, but may be something that’s crept in as the overall patch has gotten bigger and more complex. But there shouldn’t be any issues with pattrstorage with a large patch should there?
I don’t think patcher or data size has much to do with it. The patcher I’m working with is relatively small in comparison to many projects. The data being stored is text, numbers, and a few umenu and other ui things. I think there’s like 13 total tiny entries, and only a single slot of data.
Maybe use the message "purge" on the pattrstorage to clean the erroneous data?
Is the effect of purge different from clear? (I’ll have a look tomorrow anyway).
I solved my issue after another few hours digging around and trying things out. It turned out there was an old [t b] left over in part of the patch that was retriggering a umenu unnecessarily. I’m not sure why it would only affect one or two of the umenus, but i took it out, and so far settings seem to be being recalled correctly. I also went through a lot of the sub patchers and gave specific patcher-related names to UI objects, just in case there were any potential name conflicts (does that actually make anydifference?)
And one thing I’m having to pay _much more attention to when a new scene is recalled, is the ordering of messages, and making sure that loading of buffers and menus happens at the right time.. _Lots of trigger objects .
So maybe that’s relevant in your patch. Take a careful look at the order in which things happen. Maybe the settingsmin pattrstorage are being recalled, but then immediately set to something else by another message (that’s what was happening in my patch).
The other thing that might affect things is the priority of the different settings stored in pattrstorage. There’s info about that in the help patch.
umenu object at a bug, maybe it has a responsibility, you can find the updated umenu object on the incremental updates page.
@Moze – My problem isn’t with erroneous data though. My data is being stored correctly, but not being recalled after a computer reboot.
I did some experimenting today and I might’ve found the problem. I’ll report back when I’ve had time to test it properly.
after similar issues with pattrstorage and recalling presets, I found that setting priorities in the clientwindow solved the problem in my case. The fact is that patterized object are recalled following the order of the clientwindow list, and not right-to-left and top-to-bottom usual max logic, which can sometimes give unexpected results.
I didn’t look at your patch, and it’s just my 2 cents, but maybe you should try that.
Phil
@phijel
I would say the inverse, preset restores in unknown order (you might get lucky, or the order doesn’t matter in some cases), patttrstorage lets you define the order ;-)
errr…Yes, this is exactly what I was saying in my post, maybe I was unclear, (and I wasn’t talking about the preset object but the way pattrstorage handles presets (or "storage slots" to be precise)
Ph
I found the problem Last night, I think. I’ve tested it once, and it worked. I’m going to do some more testing before I’m sure though.
I attached a print to the pattrstorage, and I noticed that when the loadbang occured, it would call up the filename followed by a 0. I recall that the 0 in presets is used only as a cache for interchanging. I’m guessing that rebooting the computer emptied this cache, and so it wouldn’t load anything.
The weird thing is, it also triggers a preset object on a delay, so after the pattrstorage loads its file, and so in theory, that would load up the data. Apparently not.
Now, I’ve instead routed it so that the preset recall and store messages are being sent to the pattrstorage itself, and after the XML is loaded, the pattrstorage is told to load slot 1….it seems to work. When I’m done testing this thing, I’ll post a modified patch to show what I did.
I must have done something wrong, because what I thought was a solution makes the compiled program crash.
As I noted in my previous post, the pattrstorage reports thru print that it is loading "[filepath]/prefs.xml 0" — I assume this means it is loading slot 0. Is there a way to tell it to load slot 1 in this same operation?
"[filepath]/prefs.xml 0" actually means the file was not loaded successfully into pattrstorage.
Hm. Okay, ignore almost everything I’ve written so far. I’ve had a few errors from other sources, which I found after using @outputmode 2. I switched how I was using my autopattr (I used to use physical connections, now I just let it pick up all named objects) and it was picking up a corrupted object. That was interfering with a lot of things. I also made a series of very elementary mistakes while working on fixing this, which made it much harder.
Second, I thought I had a solution, and it turns out I didn’t. And as ^^Spectro^^ just pointed out, my assumptions on some things were terribly wrong.
The origin of my specific problem has to do with the loading of the program after reboot. The settings in the pattrstorage are loaded by a loadbang. I had the actual recall of the presets on a delay of 2 seconds, to give the software time to load (it isn’t particularly large, either). After rebooting, the first time you launch a program, it takes longer to load. I set the loadbang on a 30 second delay this time, and it worked fine!
It seems as if the loadbang was executing before the patcher had the ability to do all of it’s functions. Is there any other way to go around this? I would like to reduce the timer, but I am hesitant, since my users may have varying system speeds, and it may take longer for them to launch, in which case, it would lose the proper loading, which actually defeats the whole purpose of the program.
One method which is very often safe, is to use a deferlow object after the loadbang. Another method, which is sometimes required when the first method does not work, is to query info from the object in question, until it replies. Then you know it’s there and ready to go. Using the read confirmation from the pattrstorage for instance is a safe method to trigger events after being certain that a preset file has loaded fine.
@jvkr
Thank you. This fixed it right up!