So I’m running into the same old problem that used to occur with the preset object: you create some objects, create some presets, then create some more objects, then create a few presets with them. The problem is that the old presets don’t know anything about the new objects, so they have a bunch of unset values.
Is there a way to force pattrstorage to re-save all current client values for a slot? I’m using the preset object in conjunction with pattrstorage and it is definitely a no go. (Max 6.0.4)
I don’t think there is a way to automagically ‘fix’ your old presets – how would you determine what values the new objects should have in your old presets?
I’d be interested in hearing otherwise (having run into the posted issue before), but I can think of no better method than programmatically recalling then storing each slot in your old preset file (then writing the file back to disk). Obviously this will only add the ‘current value’ of each new object into your old preset (which may or may not be better than having ‘no value’ stored…)
Not looking for a magic fix, just want the new objects to store with the old objects when I store the preset (after recalling the old preset) a second time. It’s not storing unless I go in and manually "change" the new objects before storing. Seeing as how I have several hundred, I’d like to not do this…
I’m wondering if this is an issue with the way preset and pattrstorage interact.
The documentation says that it’s for entries that have moved/been deleted, so I’m not sure.
I isolated it further, and it’s an abstraction with M4L objects in it (albeit using pattr), so I think that may be part of it. When I converted it into a subpatcher, it was fine, so, for now, that’s what I’ll go with. (before that the objects were grayed out in the parameter view and empty in the pattrstorage storage window)
This is for my model of the EML-200. I’m posting the project source soon, and am trying to get the presets together.