Wishlist — pattr attributes rolled into the objects
Sorry if this has been "wish-listed" before:
Instead of pattr being a collection of separate objects, roll pattr-type attributes into objects themselves. e.g., autorestore, visibility to hierarchy, visibility to pattrstorage, recall priority, etc.
I envision opening the object’s inspector and seeing all these attributes (including the inspector for bpatchers, and somehow managing this for patchers and subpatchers).
Putting aside your notion for built-in pattricity for a moment, there
are certain attributes which conceptually belong to pattrstorage, and
others which are arguably suitable for pattr. Let’s look at yours
(and a few others) – keep in mind, none of these will be available
before Max 5, if at all. But as an exercise.
@thru: whether the pattr object outputs upon receiving a new value,
or whether it waits for a bang. this belongs to pattr.
@autorestore: i’m not sure what you mean here. Whether the pattr
object auto-restores on load is already there as an attribute.
Presumably you mean something else.
@visible_to_hierarchy: also not sure what you mean here
@visible_to_pattrstorage: belongs to pattr, assuming that you want to
set this on a global level.
@priority: I maintain that this belongs to pattrstorage, although I
see the argument for being able to specify an initial value, which
could be overridden by psto.
@store: I don’t know what Stefan meant here, so I need more info.
Am 13.05.2007 um 22:51 schrieb Adam Kendall:
> Sorry if this has been "wish-listed" before:
> Instead of pattr being a collection of separate objects, roll pattr-
> type attributes into objects themselves. e.g., autorestore,
> visibility to hierarchy, visibility to pattrstorage, recall
> priority, etc.
> I envision opening the object’s inspector and seeing all these
> attributes (including the inspector for bpatchers, and somehow
> managing this for patchers and subpatchers).
As a programmer-at-large, I understand your position of what attributes belong where. As a *Max* programmer, regardless of what’s best-practices or not, I keep expecting certain attributes to be local to the object in question.
So, no arguments from me, just lists of wishes.
@visible_to_hierarchy — I mean the ability to allow an object to be visible to the pattr hiearachy for control purposes but not stored in pattrstorage. Example — I want to control an hslider by a pattrfoward in another patch, but I don’t want the hslider’s value stored in the pattrstorage that’s saving all of its friends.
I know there are ways to do this, but I’d like this to be an attribute local to the object (or a pattr managing the object), not something I have to manage with the pattrstorage.
This stems from constantly reusing patches. Instead of setting the attribute once in the subpatch, I have to remember to manage the different pattrstorages managing my different applications.
Jeremy Bernstein schrieb:
> @store: I don’t know what Stefan meant here, so I need more info.
It was Mattjis and I guess he ment the same as Adam with
@visible_to_pattrstorage. He seems to be d’accord that it belongs to
pattr, though it sounded different… ;-)