pattrstorage not saving unchanged parameters?
Hi everyone!
I've been experiencing a weird behavior using pattrstorage.
It looks like certain parameters are not being saved unless manually being tweaked before saving...
I have a patch with many elements on gui, and it's really annoying having to tweak everything to store parameters properly.
any idea of what could be happening?
thanks!
that's not normal. Either they aren't exposed to pattr system, or you're trying to save slot number 0, or i don't know. can't help more without a patch.
I think it is related to the fact that i've been storing presets while still developing.
As i was adding more and more parameters associated with pattr everything started to mess...
I just removed everything on pattrstorage using "clear" and started storing again, and it looks like everything is fine now...
I'll let you know if i confirm this solves the issue...
That is most probably the cause - in my experience, pattrstorage doesn't behave well if you've already saved a bunch of presets and then add more objects to the system - it's best to get all of your objects in place before you start putting in a lot of time tweaking presets. Would be nice if it were more forgiving, but it's not surprising that it gets confused.
If you add an object after creating a preset, of course this object will have no previously recorded state for that preset - so whatever your other recorded states are, the ones that aren't yet recorded will be untouched by pattrstorage. You need to store preset again. This in itself can be confusing, but i don't remember having unexpected behaviour after i re-stored a slot with a newly created object.
To confirm pseudostereo's comment - I've had lots of problems with pattrstorag once I start editing any of my existing large patchers. Like adding extra modules, making changes to existing modules and so on.
Pattrstorage actually seems to be petty good at picking up new objects, which of course you then need to store a setting for. The main issue I've is that suddenly the hierarchy of a module is lost (i.e. In the settings listing, the objects jump to the same hierarchical level as the name of the patcher. And all the settings for those objects are lost. This gets saved into the json file. Thereafter no settings are stored from that module.
I've occasionally managed to reset things by deleting and recreating the autopattr object inside a "faulty" patcher, but then it tends to "go wrong" again after a while.
In the end I created new bpatchers containing the UI objects and fresh autopattrs and so far they've been working ok. Though of course I had to recreate all the settings.but I was having to do that anyway!
I've also found that occasionally a save to disc operation will cause some damage to the json file (usually lost settings). SublimeText 2 has been an absolute godsend for modifying multiple discontiguous lines in a file (i.e. Settings for one object across several presets) all at once. The time the app has saved me in fixing settings file has made the cost worthwhile.
Obviously it's best to completely finish a patcher before you start on the storage system. But if you're working with a large, gradually evolving system, that's not really feasible!
Yes, i can confirm that deleting json files, and recreating the pattrstorage object actually works. That means loosing previous stored data, but at least it is possible to work and make fresh presets with no errors.
Vichug, unfortunately storing the preset again doesn't work when everything has been already messed up by this issue. It looks like parameters not being saved the first time are not going to be saved when re-storing, unless you tweak previously the parameter... which is annoying if you have hundreds of gui elements.
ah, i see now, i remember someone mention this issue (re : nested autopattr's and stuff) on the forum. After some search, it was indeed one of your posts David... If i remember the problem is that pattrstorage loses the subpatcher adress because it doesn't like the @name attribute of autopattr when it's different from the subpatcher's name from which it is inside. Alsoo.... maybe using a pattrmarker object would help...