[feature request] grab works when encapsulated

Apr 2, 2008 at 1:06pm

[feature request] grab works when encapsulated

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.

#P window setfont “Sans Serif” 9.;
#P number 263 181 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P message 263 114 30 196617 bang;
#N vpatcher 30 89 630 489;
#P outlet 70 87 15 0;
#P inlet 50 25 15 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 50 135 77 196617 print GRABBED;
#P newex 50 50 30 196617 grab;
#P connect 2 0 0 0;
#P connect 0 0 1 0;
#P connect 0 1 3 0;
#P pop;
#P newobj 263 153 57 196617 p grab_me;
#P connect 0 0 2 0;
#P connect 1 0 0 0;
#P window clipboard copycount 3;

#36689
Apr 3, 2008 at 4:30pm

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.

#126063
Apr 4, 2008 at 12:49pm

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

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

Ciao.

#126064
Apr 4, 2008 at 2:52pm

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.

jb

#126065
Apr 4, 2008 at 4:10pm

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.

#126066
Apr 6, 2008 at 2:40pm

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.

#126067

You must be logged in to reply to this topic.