Guillaume Evrard

i'm looking for a way to autoname my abstractions. i tried this simple (and stupid?) solution :

but i'm not sure about the use of thisobject, and it's not documented in the reference manual.

the fact is that i would like my abstractions named with #0_something, in order to use them in bpatchers and being able to manipulate their dimensions.

i'm sure you already a have the solution :)

autonaming-objects

> i'm looking for a way to autoname my abstractions. i tried this

I have no clue what you mean with "autoname" your abstraction, and it 

doesn't seem to be a solution for you either...

> but i'm not sure about the use of thisobject, and it's not documented

But it has a help file with some red letters in it...

> the fact is that i would like my abstractions named with

> #0_something, in order to use them in bpatchers and being able to

If you patch by hand, you can just give them a name, if you script they 

Or did you miss the tutorials/manuals...???

guillaume schrieb:
> i'm looking for a way to autoname my abstractions. i tried this
> simple (and stupid?) solution :

I have no clue what you mean with "autoname" your abstraction, and it 
doesn't seem to be a solution for you either...

> but i'm not sure about the use of thisobject, and it's not documented
> in the reference manual.

> the fact is that i would like my abstractions named with
> #0_something, in order to use them in bpatchers and being able to
> manipulate their dimensions.

If you patch by hand, you can just give them a name, if you script they 
will have a name. What is the problem?
Or did you miss the tutorials/manuals...???

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


yes i saw this red letters, i was just hoping they wasn't real...

i'm tryind to have an UI in a bpatcher, with two view modes (compact & extended), so i need to resize my bpatcher by clicking a button in it. But the only solution i've found is to name the bpatcher and modify its size by scripting in the parent patcher.

now, if i want to have more than one of this UI in the same patch, i need to give them different names. it's ok to do it manually with 10 objects, but with 100... that's why i would like to autoname these bpatchers (maybe using an autopattr in the parent patcher), i think i will have to mxj this...

i'm tryind to have an UI in a bpatcher, with two view modes (compact & extended), so i need to resize my bpatcher by clicking a button in it. But the only solution i've found is to name the bpatcher and modify its size by scripting in the parent patcher.
now, if i want to have more than one of this UI in the same patch, i need to give them different names. it's ok to do it manually with 10 objects, but with 100... that's why i would like to autoname these bpatchers (maybe using an autopattr in the parent patcher), i think i will have to mxj this...

Quote: G. wrote on Thu, 31 May 2007 09:22

----------------------------------------------------

> now, if i want to have more than one of this UI in the same patch, i need to give them different names. it's ok to do it manually with 10 objects, but with 100... that's why i would like to autoname these bpatchers (maybe using an autopattr in the parent patcher), i think i will have to mxj this...

https://cycling74.com/forums/index.php?t=msg&th=25880&rid=0&S=a8f5863a664d8000eb965389f741637c

it shows you how to extract the #0 value from a bpatcher :

put [loadbang]-[#0]-[outlet] into your bpatcher

from there it should be simple to generate the necessary scripting messages to resize your individual bpatchers.

Quote: G. wrote on Thu, 31 May 2007 09:22
----------------------------------------------------

> now, if i want to have more than one of this UI in the same patch, i need to give them different names. it's ok to do it manually with 10 objects, but with 100... that's why i would like to autoname these bpatchers (maybe using an autopattr in the parent patcher), i think i will have to mxj this...
>
> G
----------------------------------------------------

it shows you how to extract the #0 value from a bpatcher :
put [loadbang]-[#0]-[outlet] into your bpatcher

 from there it should be simple to generate the necessary scripting messages to resize your individual bpatchers.

i know, i was trying to set the parent patcher name via mxj but it seems this method is not implemented...

that's ok, i managed to make this working correctly.

it seems the [deferlow] is very important in the patch you gave me Patrick.

> i'm tryind to have an UI in a bpatcher, with two view modes (compact

> & extended), so i need to resize my bpatcher by clicking a button in

> it. But the only solution i've found is to name the bpatcher and

> modify its size by scripting in the parent patcher. now, if i want to

> have more than one of this UI in the same patch, i need to give them

> different names. it's ok to do it manually with 10 objects, but with

> 100... that's why i would like to autoname these bpatchers (maybe

> using an autopattr in the parent patcher), i think i will have to mxj

Did you ever actually try? make a bpatcher, give it a name. Then 

duplicate it (one keystroke) now look at the name of the duplicated 

It should be no problem that the names have a specific format, its part 

of the solution, that way you can calculate the names easily for your 

guillaume schrieb:
> i'm tryind to have an UI in a bpatcher, with two view modes (compact
> & extended), so i need to resize my bpatcher by clicking a button in
> it. But the only solution i've found is to name the bpatcher and
> modify its size by scripting in the parent patcher. now, if i want to
> have more than one of this UI in the same patch, i need to give them
> different names. it's ok to do it manually with 10 objects, but with
> 100... that's why i would like to autoname these bpatchers (maybe
> using an autopattr in the parent patcher), i think i will have to mxj
> this...

Did you ever actually try? make a bpatcher, give it a name. Then 
duplicate it (one keystroke) now look at the name of the duplicated 
bpatcher...

It should be no problem that the names have a specific format, its part 
of the solution, that way you can calculate the names easily for your 
scripting....

that should be a part of solution. but i'm patching an application that's not for me, but for users who don't have max skills. So i need to make things a bit automatic... and naming objects is something everybody forget or don't want to bother with...

um? script new nyname mytupeofobject syntax with thispatcher?

On May 31, 2007, at 5:19 PM, guillaume wrote:

> that should be a part of solution. but i'm patching an application 

> that's not for me, but for users who don't have max skills. So i 

> need to make things a bit automatic... and naming objects is 

> something everybody forget or don't want to bother with...

>
> that should be a part of solution. but i'm patching an application  
> that's not for me, but for users who don't have max skills. So i  
> need to make things a bit automatic... and naming objects is  
> something everybody forget or don't want to bother with...
>
> g.

if you create a bpatcher by this way, you will have to specify different names if you want more than one of them in the same patch.

maybe using a [sprintf script new name-%i myobject ...]-[thispatcher] could do the work with a counter. this is "autonaming" but not "selfnaming". i would like to make this the more transparent as possible.

the JS Patrick gave before in this thread works fine. (even if i'm not really in love with JS...)

if you create a bpatcher by this way, you will have to specify different names if you want more than one of them in the same patch.
maybe using a [sprintf script new name-%i myobject ...]-[thispatcher] could do the work with a counter. this is "autonaming" but not "selfnaming". i would like to make this the more transparent as possible.
the JS Patrick gave before in this thread works fine. (even if i'm not really in love with JS...)

> that's not for me, but for users who don't have max skills.

So naming of objects is your part and not that of the users...

> So i need to make things a bit automatic... and naming objects is

Why should they, I can't imagine why a user would need to name objects 

Maybe its time to tell us what you actually want to do...

guillaume schrieb:
> that should be a part of solution. but i'm patching an application 
> that's not for me, but for users who don't have max skills.

> So i need to make things a bit automatic... and naming objects is
> something everybody forget or don't want to bother with...

Why should they, I can't imagine why a user would need to name objects 
which have names already...
Maybe its time to tell us what you actually want to do...

i just want to resize a bpatcher from inside the bpatcher (let's say by clicking a button wich is in the bpatcher), that means the bpatcher has to be aware of its own name, to send the right script lines to the upper patch.

that works fine with JS and a send to the upper patch.

i just want to resize a bpatcher from inside the bpatcher (let's say by clicking a button wich is in the bpatcher), that means the bpatcher has to be aware of its own name, to send the right script lines to the upper patch.
that works fine with JS and a send to the upper patch.
g.


On 1 juin 07, at 09:02, Stefan Tiedje wrote:

> Why should they, I can't imagine why a user would need to name objects 

> Maybe its time to tell us what you actually want to do...

If Guillaume, and I, and maybe others, think it's a good idea to 

autoname patchers, I hope there must be some reasons :-)

In my case, I use some [bpatcher] with an argument, and want this 

argument to be part of the name of the [bpatcher]'s instance. I found 

it much more easy to have the [bpatcher] naming itself automatically 

once instantiated than having to type in an argument in the inspector 

As a side effect, if I use this [bpatcher] in a couple of monthes, I'm 

sure that, despite any comments I could add in the patch, I will forget 

to name it the right way. Now, with this autonaming technique, I know 

it will have a name and will be visible to [autopattr].

There may be other ways to do this, and this is just one of them...

Centre de Recherches et de Formation Musicales de Wallonie asbl

> Why should they, I can't imagine why a user would need to name objects 
> which have names already...
> Maybe its time to tell us what you actually want to do...

If Guillaume, and I, and maybe others, think it's a good idea to 
autoname patchers, I hope there must be some reasons :-)

In my case, I use some [bpatcher] with an argument, and want this 
argument to be part of the name of the [bpatcher]'s instance. I found 
it much more easy to have the [bpatcher] naming itself automatically 
once instantiated than having to type in an argument in the inspector 
AND the correct name.
As a side effect, if I use this [bpatcher] in a couple of monthes, I'm 
sure that, despite any comments I could add in the patch, I will forget 
to name it the right way. Now, with this autonaming technique, I know 
it will have a name and will be visible to [autopattr].

_____________________________
Patrick Delges

Centre de Recherches et de Formation Musicales de Wallonie asbl
http://users.skynet.be/crfmw/max


If there is a pattr or autopattr object inside of a subpatcher, even 

if it's unused, it will automatically name the patcher's box (and any 

patchers between it and the top level of the patcher) when it loads.

I haven't really been following this discussion, but that appears to 

Am 01.06.2007 um 00:45 schrieb guillaume:

> if you create a bpatcher by this way, you will have to specify 

> different names if you want more than one of them in the same patch.

> maybe using a [sprintf script new name-%i myobject ...]- 

> [thispatcher] could do the work with a counter. this is 

> "autonaming" but not "selfnaming". i would like to make this the 

> the JS Patrick gave before in this thread works fine. (even if i'm 

If there is a pattr or autopattr object inside of a subpatcher, even  
if it's unused, it will automatically name the patcher's box (and any  
patchers between it and the top level of the patcher) when it loads.

I haven't really been following this discussion, but that appears to  
be what you're trying to do.

>
> hello vade,
>
> if you create a bpatcher by this way, you will have to specify  
> different names if you want more than one of them in the same patch.
> maybe using a [sprintf script new name-%i myobject ...]- 
> [thispatcher] could do the work with a counter. this is  
> "autonaming" but not "selfnaming". i would like to make this the  
> more transparent as possible.
> the JS Patrick gave before in this thread works fine. (even if i'm  
> not really in love with JS...)
>
> g.
>


> If there is a pattr or autopattr object inside of a subpatcher, even if 

> it's unused, it will automatically name the patcher's box (and any 

> patchers between it and the top level of the patcher) when it loads.

Yes, that's why I always thought its more important to retrieve an 

existing name than creating or renaming the object. If I rename it 

myself, there is a certain chance that it will either create a conflict 

I have a js which actually retrieves the number out of the 

MyBpatchername[xx] notation. That way I can easily get rid of the 

necessity of opening multiple inspectors for only changing a single number.

What is missing for me, is to retrieve the actual size of the bpatcher 

from inside probably with js as well. I want to adjust UI elements 

Jeremy Bernstein schrieb:
> If there is a pattr or autopattr object inside of a subpatcher, even if 
> it's unused, it will automatically name the patcher's box (and any 
> patchers between it and the top level of the patcher) when it loads.

Yes, that's why I always thought its more important to retrieve an 
existing name than creating or renaming the object. If I rename it 
myself, there is a certain chance that it will either create a conflict 
or is #0_UGLY...

I have a js which actually retrieves the number out of the 
MyBpatchername[xx] notation. That way I can easily get rid of the 
necessity of opening multiple inspectors for only changing a single number.
What is missing for me, is to retrieve the actual size of the bpatcher 
from inside probably with js as well. I want to adjust UI elements 
according to the size of the bpatcher...

I know this is quite an old thread but it is (was should I say) still an issue even in Max5 so... I'm just posting the solution I've recently come to.

It's been quite a long time I've been needing a proper solution to "self-name" bpatchers so you can resize from inside the bpatcher and use the name with the pattr system with a the name for the bpatcher whatever the parent patch it is in as G. described.

I tried also with thisobject and it was kind of working but had some errors, conflicts and sometimes erratic behaviours.

So I've finally taken the time to try with javascript as mentioned above. I wrote a script to put in the bpatcher which will give the bpatcher the name you type in as an argument or you send as a message to the js box. It works also with abstractions and subpatches which can be useful and just don't do anything if the patch is not loaded "inside a box" (ie as an abstraction, a bpatcher or a subpatch).

As sharing is fun I attached the script. Any comment, remark, suggestion is welcome !

It's been quite a long time I've been needing a proper solution to "self-name" bpatchers so you can resize from inside the bpatcher and use the name with the pattr system with a the name for the bpatcher whatever the parent patch it is in as G. described.
I tried also with thisobject and it was kind of working but had some errors, conflicts and sometimes erratic behaviours.

On 23 juil. 08, at 11:50, BenCello wrote:

> I know this is quite an old thread but it is (was should I say) 

> still an issue even in Max5 so... I'm just posting the solution I've 

> As sharing is fun I attached the script. Any comment, remark, 

I use this technique since a long time with Max4 and it seems to work 

only when the call to the naming function is deferlowed. I suppose 

The autonaming from arg is a nice idea, but the schedule(250) is quite 

arbitrary, although I can't find any other workaround. And anyway, as 

the name is saved in the patch, autonaming is probably only usefull 

once, when the patcher/abstraction/bpatcher is first instantiated, so 

this 250ms delay won't prevent [pattrstorage] to find its clients as 

> I know this is quite an old thread but it is (was should I say)  
> still an issue even in Max5 so... I'm just posting the solution I've  
> recently come to.

> As sharing is fun I attached the script. Any comment, remark,  
> suggestion is welcome !

I use this technique since a long time with Max4 and it seems to work  
only when the call to the naming function is deferlowed. I suppose  
it's safer even in Max5.
The autonaming from arg is a nice idea, but the schedule(250) is quite  
arbitrary, although I can't find any other workaround. And anyway, as  
the name is saved in the patch, autonaming is probably only usefull  
once, when the patcher/abstraction/bpatcher is first instantiated, so  
this 250ms delay won't prevent [pattrstorage] to find its clients as  
they already have names.

Centre de Recherches et de Formation Musicales de Wallonie asbl
http://www.crfmw.be/max


Autonaming objects