something between [v] and [pvar] or [pattr] that crosses patchers/subpatchers ?
Hello,
In a patch with subpatchers i want to send a named value and keep it stored at the same time from and to several objects ; i’d like to avoid using send/receive because with those objects it’s not as easy to be able either setting or receiving a new value, and storing it for banging later if needed.
The problem with [v] ( or [value] ) is that it doesn’t update automatically when one is changed. Otherwise [v] would be perfect here…
The problem with [pvar] is that it doesn’t cross subpatcher boundaries. Otherwise, once again, it would be ideal…
The problem with [pattr] is that, alone, it does neither cross subpatcher boundaries…
the problem if i had to use a complet [pattrstorage] setup is that i don’t really want nor need to save those values, and it would seem a bit overkill… also you can’t have multiple [pattr] bound to a non-existent object (i mean, you need one ui element that is named and to which you are binding).
Hmm… multiple solutions, none ideal, the closest/easiest right now seems [s] and [r]. but if there is anything better ?…
In the folder examples>max-tricks>send-receive-tricks there is an approach that might be suitable.
It boils down to this:
<code>
</code>
Hey, thanks, but this is not really satisfactory because it doesn’t remember what is inside – i mean, with [v] you can bang the object at anytime which outputs the stored value ; plus the loop feedback is not really a problem in my case. But anyway what i do is with sends and receives that stock the value once it’s received, not as cool as [v] in the sense that if you create a new receive somewhere you’ll have to re send the value, but it’s ok for my needs.
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.
Hi Myr, thanks for the insight ;
[v] : that’s what i meant :)
[pvar] : i didn’t succeed in observing the behaviour you descrive. If i have a pvar of a certain name in my toplevel patcher, no subpatch will access this pvar, regardless if i have ui object with the same scripting name on that level or not. i’m on 6.1.3. Could you please share a patch that is working for you ? i would be interested, and it’s possible i didn’t get well how to use this [pvar]….
[pattr] : exact same comment as [pvar]…
[pattrforward] is cool, but the problem with scripting names is that you can not share scripting name between two objects of the same class at an identic patcher level. but i’d like to avoid as much as possible the [pattr] realm, because here it’s a bit overkill, and sending messages to objects through their scriptng name can quickly get cpu intensive… well htat’s from my experience anyway, working with pattrstorage, and a lot of named objects and of messages, so maybe it was just normally cpu intensive…
[pattrhub] : oh i see now, the subpatcher adressing syntax is special. Well thre might be a solution, but it would be far less rapid easy intuitive whatever than the automatic way [v] or [s]/[r] go in and out subpatchers…
@op i don’t know what do you want exactly, but I tend to use pattr in similar situations [see below]. Down the road I usually want to manage data with pattrstorage.
@myr excellent set of tips!
<code>
</code>
[v] then should have some sort of notify_all attribute.
Or even better, in the fantastic manner as with gen~, that a declared value [v pi] can be referred to in expressions and other objects: [expr $f1*2*pi].
@Jvkr : yes, yes, that would be indeed incredibly awesome ^^
@Andrzej Kopec : thanks, this is useful. Didn’t know you had that parent:: adress possibility.
Can you not jury-rig something with a combination of [send], [receive] and [v]? [s/r] will transcend patcher boundaries happily. The whole point of pattr and pvar and all the other patcher-specific methods was to give some kind of encapsulation, as a counterweight to the global tell-everyone nature of [s/r].
It should be possible to build the behavior you require.
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.
the main thing i’ve been trying to work on in this area, and finding frustrating, is the basic programming idea of defining a function/method somewhere in a max patch. then being able to call this method and have it return a value to where it was called from. without having to set up loads of complex cable wiring with [s]/[r] or [route] and [gate].
nearly getting close when i put the function/method into a subpatch or patcher, give that patcher a scripting name and then send messages to it using [pattrforward]. returning values is still a bit of an arse tho, currently using [s] and [r] still. if only [pvar] worked accross patcher hierarchies like [pattr] can.
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.
hey myr,
have a look at:
http://cycling74.com/forums/topic/sharing-is-fun-oo-objects-for-max/
the oo.objects are for max 5, but seem to address your concern here to some extent…
(old thread, looks like project may be dead now, but interesting nonetheless)
@Peter Castine : sure it is. That’s what i do at the moment :) with [s]/[r] and [f]. But it’s not as practical as, e.g., a [v] with @autoupdate 1 would be, definitely. What bothers me is that you have several objects that do, each of them, one of the thing i want, or more combined, but never all… and still some seem redundant….
@myr and @floating point : i had a look at oo objects, it should be good for what you describe Myr ! though not that much for my current concern :)
depending on the type of data you want to store/hold/pass you could also use named jitter matrices…
@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.-)
"if you really want a dedicated external to do something, you grab XCode or Visual Studio and build the dedicated external."
if i could, i would ;) (probably. But i’ve been running to that kind of problem several times so it would maybe be worth it ?)
matrices are nice indeed, not that much for just sharing one variable.