gusanomaxlist

I think it would be cool to have [grab] working when encapsulated while the object that receives the message is out of the patcher.

I always have errors "outlet: doesn't understand ...".

I guess it's an expected behaviour as [outlet] is an object like others, but in complicated patches, with tons of patchers, I'd find handy to have some grabs inside patchers so my patches stay clean ;)

I'd like to know what you think about this.

Hi.
I think it would be cool to have [grab] working when encapsulated while the object that receives the message is out of the patcher.
I always have errors "outlet: doesn't understand ...".
I guess it's an expected behaviour as [outlet] is an object like others, but in complicated patches, with tons of patchers, I'd find handy to have some grabs inside patchers so my patches stay clean ;)
I'd like to know what you think about this.
Cheers.

feature-request-grab-works-when-encapsulated

I love the grab object, or at least I use it a lot and tend to feel it gets ignored in situations where it's useful. I understand from earlier discussions, however, that the way it works is inconducive to allowing it to pass through an outlet object.

Furthermore, I gather that the way it works internally is ugly and some people would prefer to dump it. It is unlikely to be dumped because it _is_ used a lot. But as objects continue to be attributized, the dumpout option is cleaner.

For Litter Power I've added a 'tell' message to objects with the syntax tell . The object receiving the message simply sends the value[s] of the attribute to all receive objects with the name . Simple to implement (particularly once an object is attributized, which does involve some work) and leads to neater patches than the dumpout convention. It also allows objects to evolve new outlets over the years (something dumpout rather discourages).

I'd encourage other developers to look at the tell mechanism and consider implementing it (or something similar). It's dead useful.

For Litter Power I've added a 'tell' message to objects with the syntax tell  . The object receiving the message simply sends the value[s] of the attribute to all receive objects with the name . Simple to implement (particularly once an object is attributized, which does involve some work) and leads to neater patches than the dumpout convention. It also allows objects to evolve new outlets over the years (something dumpout rather discourages). 

I'd encourage other developers to look at the tell mechanism and consider implementing it (or something similar). It's dead useful.


Oh yes, please dear developers, think about that !)

By the way, thank you for all those nice 3rd party objects!

This kind of functionality can already be had, without any work on the part of any developer: use pattr to subscribe to the attribute -- 'bindto object::attribute', which works as long as the target object has a patcher scripting name. You'll get output every time the attribute changes.

In Max 5, you can turn the @invisible attribute of the pattr object on, if you only want to use the object for this functionality (rather than for presets).

So, unless you object to naming the objects you want to hear about, you're set up.

This kind of functionality can already be had, without any work on the part of any developer: use pattr to subscribe to the attribute -- 'bindto object::attribute', which works as long as the target object has a patcher scripting name. You'll get output every time the attribute changes. 

The thing is that I am now dealing with objects without attributes so I still have to use un-encapsulated [grab].

Thanx for the tip!
The thing is that I am now dealing with objects without attributes so I still have to use un-encapsulated [grab].
Ciao.


True, I keep on forgetting some of the things you can do with pattr. In my defense, I had a need for something like a 'tell' message before pattr had been invented, so I did some inventing of my own. And everyone grows fond of his own inventions.

[feature request] grab works when encapsulated