something between [v] and [pvar] or [pattr] that crosses patchers/subpatchers ?

In the folder examples>max-tricks>send-receive-tricks there is an approach that might be suitable.

It boils down to this:

<code>

----------begin_max5_patcher----------
388.3oc2TEsaBBCE8Y3qnoOyVnHR11GxdYwXJvcZMXgzVT1L9uu1aAEWlIt4
hIa7vs4d5sm6gC2xtv.ZdcGnojmHuPBB1EFDfPNff97.5ZdWQEWikQksqyAE
MxukMqt0TAFbyjdTOj4sFvyLUHMzHBMmKWPIy5q50ZoQKdGqgwtOdDrjuFgo
OCpRtjOztFtoXoPtXtBJLdtYoo1iNrLM1ESrwCswJQgbPgrdPQIRec9p6xNR
tx1VCnlCRddEJfX2V6CCcgn+nNTR1U5Po+5NDr0x6.qFnCUJUukzYe9ZmicN
m621tlvRFaWS+11UxAxUfFjFtQTKG2f3LeCdvsD2GHy9uYjrGuRijQGYI3on
UB4m+cE1YG9o9jttUUL7p0eOmbr2kf1Hj3mlQ0vNolkhxR.2dvAJEZ2be44G
7uT0vt.0jcyTS5EnljalZRt.0j9CUieLh2zrAT5dJQgXuXspV4RyhvTgzmhC
lTErQLT+DDgqrC7F6zdqxeinKK0NvZ6y9vO.L9RsKC
-----------end_max5_patcher-----------

</code>

yeah, i often find the need for an object somewhere between these. still haven’t found a perfect solution or workflow to deal with it the way i want, but i’ve come up with a few workarounds. couple of points:

- [v] / [value] should update when one is changed, they won’t output though if that’s what you meant.

(edit: mistake here, meant to talk about the [pv] not [pvar] object) – [pvar] doesn’t cross patcher boundaries… unless there’s a copy in a higher level patcher in the hierarchy. if i’m using [pvar] i’ll usually first make them all in the top level patcher of the app/module. then the [pvar]‘s can be seen in any patchers or subpatchers of the highest level patcher of the app/module.

- [pattr] can cross patcher boundaries if you use the “bind to” attribute and use the correct message to set the path.

- you can’t bind a [pattr] to a non-existant object, but you can bind it to another [pattr] or to most objects with a scripting name, ui or non-ui.

- scripting names are also really useful, especially for getting round having too may send and receives, when combined with [pattrforward]. [pattrforward] can work across patcher boundaries and can also talk to the object box itself and any of its inlets. also works with any object with a scripting name, not just pattr objects as the object name might imply.

- [pattrhub] lets you send messages to any “pattrised” object, so [pattr] or bound to [pattr], and you can also get the state/value of any [pattr] object. works accross patcher boundaries.

ahhh oooops, i made a mistake earlier.

when i was talking about the [pvar] object i meant to talk about the [pv] object! which is basically a [var] object with local scope. working how i described. sorry about that. check out the [pv] help file for an example of how it can stay “public” or “private” in terms of its scope within the patcher hierarchy.

[pvar] can also be pretty awesome, but it is basically nerfed for me as it doesn’t work accross patcher boundaries at all, as far as i can tell… why o why. would be a very powerful object otherwise.

like how [pattrforward] allows us to send messages to any object with a scripting name we need a [pattrreceive], or something that combines both, to receive the output from any object with a scripting name.

@Vichug: the classic Max paradigm was simple objects that you hook up to do whatever you need. The paradigm of have-a-gazillion-objects-so-you-can-find-one-that-does-exactly-what-you-want-without-any-additional-work-on-your-part is a bit more of a Reaktor thing.

(The above may be a bit of an exaggeration, but take it as a general drift and you won’t be too far off.)

Max is getting more and more in the dedicated-object-for-every-possible-need, but there is still a certain frontier mentality in it. A man’s gotta do what a man’s gotta do and all that.

And, of course, if you really want a dedicated external to do something, you grab XCode or Visual Studio and build the dedicated external. That’s what makes Max so much fun.-)