nb : It was the same in 4.6, but we would expect the preset object to
know that some objects are missing and to adapt itself to the new
situation, do we ?

4 – delete the preset. Now you think the trouble is over.
5 – add a new one
6 – store a preset and… boom

nb : all of this was done with dac~ ON.

best

f.e

–
f.e chanfrault | aka | personal computer music
>>>>>>> http://www.personal-computer-music.com
>>>>>>> |sublime music for a desperate people|

I was hoping that this was going to be improved for Max 5 as there was always talk of improvement in the associated pattr help files.

as the preset object can be bound to a pattrstorage, I’d always bind it.
Has a lot of advantages and would probably help with this issue as well.
To transfer old presets, create a new preset object, create a
pattrstorage, bind the new preset object to the pattrstorage. Make sure
all recalled UI objects have a name. Now recall the old presets, and
store in the new one (could be automated with an uzi…).
Last step get rid of the old preset object…
Now you have a clean preset structure, and can easily kill UI’s or add
UI’s and preset should work fine.

The bug you reported, I came across as well, it might be only an issue
with imported presets from 4.6 but I am not sure…

And I have also a feature request for unbound presets. I use them to
recall parts of my main patch. For example I have rythms and I have
pitches. One preset is responsible for storing only the rythms, the
other will store only the pitches. That way I can create much more
combinations as I could recall with a single preset object.
But this construction will need a lot of cords from the “include” outlet
to the objects. If there would be a way to give preset a list of named
objects to include instead of that connections, this would be so cool…
(Same for autopattr of course…)

Stefan

–
Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com