Wishlist — pattr attributes rolled into the objects

May 13, 2007 at 8:51pm

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).

Adam

#31898
May 15, 2007 at 1:45pm

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.

jb

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).
>
> Adam

#104132
May 17, 2007 at 12:35pm

Hey, Jeremy,

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.

Make sense?

Thanks.

Adam

#104133
May 18, 2007 at 3:56pm

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… ;-)

Stefan


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

#104134

You must be logged in to reply to this topic.