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

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.  

wishlist-pattr-attributes-rolled-into-the-objects

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. 

@visible_to_hierarchy: also not sure what you mean here

@visible_to_pattrstorage: belongs to pattr, assuming that you want to 

@priority: I maintain that this belongs to pattrstorage, although I 

see the argument for being able to specify an initial value, which 

@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 

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

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


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.

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.

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

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.

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

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


Wishlist -- pattr attributes rolled into the objects