feature request for 'value' object (or is this available in a 3rd party object?)
I like the 'value' object. But I need to be able to set the name dynamically, e.g. via an attribute.
I'm aware that I could put it in an abstraction, add an argument, and use #1 for the beginning of the name, but I'd rather it was settable via a message or attribute. And anyway, I need to name the 'value' object based on two variables, and this isn't possible using the # notation, as you can only use one # per name, and only at the beginning of the name.
Also, I would like the 'value' object to have the option to output it's current value without requiring a bang. Currently I have to use the 'value' object in conjunction with a 'send' object to notify other 'value' objects that its value has changed.
You may ask why don't I just use the 'send' and forget the 'value' altogether? It's because I'm using M4L, and sometimes the matching 'recieve' object doesn't yet exist at the time of sending (I haven't dragged the device out yet).
Perhaps someone knows if this object already exists in some 3rd party library?
Or maybe there's some other way of doing this with standard Max objects that I haven't seen?
I think the only way you could do this is via patcher scripting, sending scripting messages thispatcher. the problem with this is that you can't directly change the name argument of a value object (or any other object) using scripting. You would have to first destroy the object and then create a new one with the different name. Of course doing this you would lose the value contained in the value object, but it may still be of use for your purposes.
Did you have a look at pattr or pvar?
@ Floating Point - I have considered using patcher scripting for this, and other, applications. However, I'm unsure of the reliability of using thispatcher to create objects: https://cycling74.com/forums/note-use-of-the-thispatcher-object-to-create-new-objects-is-not-supported/ - what's your experience? I have no problem with destroying the object when the name changes, so this could be an option.
@Tobiasros - pvar yes, but it only lets you connect to objects within a patcher. I need this to be cross-patcher, or in M4L terms, cross-device. I haven't tried pattr yet, but I think it also works within the current patcher hierarchy only.
It's probably a good project for me to write my first external, if it bothers me sufficiently!
I've only had to resort to patcher scripting in a limited cases, without problem, using max v6. it seems the 'unsupported' caveat applies to earlier versions of max.
You can also do it via js rather than thispatcher, so it seems reasonably well documented as a technique... but I'm no expert in scripting in max
Ah yes, thanks for the [js] tip. Patcher scripting is indeed well documented there, in a tutorial no less (Max JS Tutorial 2: JavaScript Scripting). I feel safer about using it now.
You could roll your own abstractions with forward:
Hey,
regarding the "output value dynamically" ; there's only pattr doing that in Max at the moment. Have had the same interrogation a moment ago...
With the pattr system you need some non intuitive conditions to make it work, but it can be really cool, rather fast :
- need one object with a scripting name, in the root of a patcher preferably
- need one pattrmarker object with a name, in the same patch as the object with a scripting name
- then you can use the following syntax with pattr objects : [pattr @bindto ::{scripting name of patcher, which is the name given to pattrmarker}::{scripting name of object}]
You need not forget the first :: ; you need a pattr for each of your object you awnt to "link", you need to connect first inlet/outlet of pattr to first outlet/inlet of the object.
THOUGH, i could understand this is not exceptionally handy (expecially if more than one instance of this patch, then need to not give several times the same pattrmarker name... also, i really don't now how this behaves in m4l regarding patcher scripting names) so if you end up writing an external that
* is able sharing a value EVERYWHERE
* is able updating that value in real time
* is storing said value, so you can output it with e.g. a bang
Then, make sure to share this ! ;)