Problem with [pattrstorage] names...
If I send [pattrstorage] a msg (from [sprinf]) that looks like "name MicChannel[1]", that means the name field in the inspector and it's storage windows should change to MicChannel[1], correct? Not happening. This is distinct from 1) the XML data file it may be reading, and 2) the scripting name (varname) in the inspector.
Thanks,
Brian
Anyone? Am I asking a dumb question or missing an easy answer? It has pretty much stalled everything...
Thanks,
Brian
I did a quick test and the name message does re-name the pattrstorage object, its just not immediately reflected in the clientwindow/storagewindow. Try renaming it and then closing/reopening the pattrstorage windows.
This does seem to change the scripting name as well as the 'pattr name'. One solution would be to send the message [name pattrName]
followed by another message [sendbox varname scriptingName].
Oh, well that's odd Had me chasing my tail for a good few days, but I *think* it's worked out now (still confirming).
On a similar note, to change the scripting name of a patcher, I should just be able to send it the msg you indicated. If I'm correct, I should also be able to use send instead of sendbox and send the same msg to [thispatcher] and it will change the scripting name of whatever patcher [thispatcher] is in. But when I do that and then re-open the inspector, the scripting name doesn't update. Is it changed or not, and what am I doing wrong?
This is getting a little frustrating, thanks for your help!
-Brian
Thanks for bringing this up; it's been fixed for the next release.
jb
Jeremey,
Which issue mentioned above are you referring to [pattrstorage] or the varname atribute? Glad to be able to contribute and that my questions are useful one way or another.
Thanks,
Brian
Changing the varname (Scripting Name from the Inspector) will now properly update pattrstorage's name attribute. And changing pattrstorage's name attribute (including by changing the box's varname) will properly update the window titles.
Great, good to know. So this is a separate issue from the one above with varname and [thispatcher]?
I'm not really clear what you're trying to accomplish with thispatcher. Are you trying to change the Global Patcher Name of a patcher (the pattrmarker name)? A quick look in the Inspector, turning on attribute names, shows that this attribute is called 'globalpatchername'. Sending the message 'globalpatchername foo' to thispatcher does change this name. Maybe you can be more explicit about what you're hoping to do. Patches which illustrate your problem, and how you're trying to solve it, are a helpful tool for us -- please take a few minutes and mock something up, so we can better understand your needs.
Fair enough...
1. I needed to change a subpatcher's (actually it's abstraction in the larger patch this came from) scripting name, as tried on the top level of the patch below. Couldn't get it to work.
2. I then realized for this need I would ideally change it from inside the subpatcher, so I figured I would use [thispatcher]. Also didn't work.
3. I hadn't heard of the 'globalpatchername' attribute and looked it up. Not sure it fits in if [pattrmarker] isn't being used, or how it might be different than 'varname'
4. Aside from the functionality stuff here, there is a larger issue about Max workflow at the bottom of this, but I put it in new topic in hopes of keeping things straight...
I have spent time with the documentation and searching the forum, which hopefully comes across, but am obviously still missing a thing or two. Hope this makes sense & many thanks,
Brian
Try this. You'll need to use JavaScript for something like this.
Here's the JS I used, save as patchernametest.js:
autowatch = 1;
function name(somename)
{
var b = this.patcher.box;
if (b)
b.varname = somename;
}
Thanks Jeremy, very cool! Works great in my initial test. I'll get to Javascript in due time...
So then, in general, changing the varname (scripting name) of any patcher is not possible through conventional Max messages to [thispatcher], but it is with JS, correct?
Thanks again,
brian