Adam Kendall

Did some checking on the forum and only found info from 2005. Want to know if anything's changed in releases since then.

1. Is there a way for pattr objects to communicate across independently opened patches instead of nested patchs

2. Is there a way for pattr objects to communicate across two independent subpatches in one master patch

I can devise scripting solutions or other workarounds, I'm trying to confirm their native behavior.

Did some checking on the forum and only found info from 2005.  Want to know if anything's changed in releases since then.

pattr-parallel-and-independent-hierarchy

Am 27.10.2006 um 14:28 schrieb Adam Kendall:

> 1. Is there a way for pattr objects to communicate across 

> independently opened patches instead of nested patchs

> 2. Is there a way for pattr objects to communicate across two 

> independent subpatches in one master patch

https://cycling74.com/twiki/bin/view/Share/JeremyBernstein

> 1. Is there a way for pattr objects to communicate across  
> independently opened patches instead of nested patchs

> 2. Is there a way for pattr objects to communicate across two  
> independent subpatches in one master patch

[1]: https://cycling74.com/twiki/bin/view/Share/JeremyBernstein


Hi, at the moment I too am fiddling with the possibilities of pattr and the nice related objects Jeremy provides on his user page. I use pattrmarker to communicate between pattrs that don't know where their counterpart is in the patcher hierarchy. It works fine :)

Only thing is, Jeremy, that pattrmarker gives an error if instantiated without a name or with a name that already exists globally. What I want to do is put the pattrmarker in an abstraction and name it dynamically according to a combination of the abstractions attributes and info the abstraction retrieves elsewhere.

Simply put: is there a way to get rid of pattrmarkers initial error message if there is no name provided?

Hi, at the moment I too am fiddling with the possibilities of pattr and the nice related objects Jeremy provides on his user page. I use pattrmarker to communicate between pattrs that don't know where  their counterpart is in the patcher hierarchy. It works fine :) 

Another interesting observation about pattrmarker (sorry for bugging you Jeremy): try to encapsulate a single pattrmarker. It says that its name is already in use. Looks like the pattrmarker is duplicated first, before the old one is destroyed.

Am 28.10.2006 um 12:49 schrieb Mattijs Kneppers:

> Simply put: is there a way to get rid of pattrmarkers initial error 

Why not provide a dummy name and replace it? I am not generally open 

to the idea of implementing "quiet" modes for objects -- errors are 

> Another interesting observation about pattrmarker (sorry for 

> bugging you Jeremy): try to encapsulate a single pattrmarker. It 

> says that its name is already in use. Looks like the pattrmarker is 

> duplicated first, before the old one is destroyed.

This is true; for the safety of your patch, the old objects aren't 

deleted until the new ones have been successfully instantiated and 

patched. I'm afraid that this is just "one of those things".

Am 28.10.2006 um 12:49 schrieb Mattijs Kneppers:
> Simply put: is there a way to get rid of pattrmarkers initial error  
> message if there is no name provided?

Why not provide a dummy name and replace it? I am not generally open  
to the idea of implementing "quiet" modes for objects -- errors are  
there for a reason!

> Another interesting observation about pattrmarker (sorry for  
> bugging you Jeremy): try to encapsulate a single pattrmarker. It  
> says that its name is already in use. Looks like the pattrmarker is  
> duplicated first, before the old one is destroyed.

This is true; for the safety of your patch, the old objects aren't  
deleted until the new ones have been successfully instantiated and  
patched. I'm afraid that this is just "one of those things".

Quote: Jeremy Bernstein wrote on Sat, 28 October 2006 14:11

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

> Why not provide a dummy name and replace it? I am not generally open 

> to the idea of implementing "quiet" modes for objects -- errors are 

I agree about the idea of a quiet mode. In this case though, not naming the pattrmarker doesn't nescessarily have to be a mistake. In my case I need multiple instances of an abstraction in which pattrmarkers are to be named dynamically. When I provide a dummy name, pattrmarker will give an error because that name already exists (see example below). If you want I can send you a stripped version of the project I'm working on, to illustrate why I need this functionality.

> > Another interesting observation about pattrmarker (sorry for 

> > bugging you Jeremy): try to encapsulate a single pattrmarker. It 

> > says that its name is already in use. Looks like the pattrmarker is 

> > duplicated first, before the old one is destroyed.

> This is true; for the safety of your patch, the old objects aren't 

> deleted until the new ones have been successfully instantiated and 

> patched. I'm afraid that this is just "one of those things".

I see. Luckily it's not much trouble at the moment, merely slows down editing a little. I'll have to restart the patch after encapsulating.

save this as an abstraction named 'abstraction':

then make this into a patch, save it, re-open it.

Quote: Jeremy Bernstein wrote on Sat, 28 October 2006 14:11
----------------------------------------------------

> Why not provide a dummy name and replace it? I am not generally open  
> to the idea of implementing "quiet" modes for objects -- errors are  
> there for a reason!

>
> > Another interesting observation about pattrmarker (sorry for  
> > bugging you Jeremy): try to encapsulate a single pattrmarker. It  
> > says that its name is already in use. Looks like the pattrmarker is  
> > duplicated first, before the old one is destroyed.
>
> This is true; for the safety of your patch, the old objects aren't  
> deleted until the new ones have been successfully instantiated and  
> patched. I'm afraid that this is just "one of those things".

> I agree about the idea of a quiet mode. In this case though, not naming

> the pattrmarker doesn't nescessarily have to be a mistake. In my case I need

> multiple instances of an abstraction in which pattrmarkers are to be named

> dynamically. When I provide a dummy name, pattrmarker will give an error

> because that name already exists (see example below). If you want I can send

> you a stripped version of the project I'm working on, to illustrate why I

try using something like "pattrmarker #0-dummy" instead. It'll generate a

On 10/28/06, Mattijs Kneppers  wrote:
>
>
> I agree about the idea of a quiet mode. In this case though, not naming
> the pattrmarker doesn't nescessarily have to be a mistake. In my case I need
> multiple instances of an abstraction in which pattrmarkers are to be named
> dynamically. When I provide a dummy name, pattrmarker will give an error
> because that name already exists (see example below). If you want I can send
> you a stripped version of the project I'm working on, to illustrate why I
> need this functionality.
>
>
Hi Mattijs,

try using something like "pattrmarker #0-dummy" instead. It'll generate a
unique name for each instance.

Quote: thijskoerselman@gmail wrote on Sat, 28 October 2006 20:06

> try using something like "pattrmarker #0-dummy" instead. It'll generate a

Hey, this works, thank you Thijs!! I've been looking all over the manuals for this functionality, couldn't find it so assumed it didn't exist, although there was a faint memory somewhere in the back of my head. Where did you find it?!

Quote: thijskoerselman@gmail wrote on Sat, 28 October 2006 20:06
----------------------------------------------------
> Hi Mattijs,
>
> try using something like "pattrmarker #0-dummy" instead. It'll generate a
> unique name for each instance.
>
> -thijs
>
>

> Hey, this works, thank you Thijs!! I've been looking all over the manuals

> for this functionality, couldn't find it so assumed it didn't exist,

> although there was a faint memory somewhere in the back of my head. Where

Actually I have no idea if and where it is documented. I probably just

picked it up from the list. It's not in the reference manual afaik.

On 10/28/06, Mattijs Kneppers  wrote:
>
>
> Hey, this works, thank you Thijs!! I've been looking all over the manuals
> for this functionality, couldn't find it so assumed it didn't exist,
> although there was a faint memory somewhere in the back of my head. Where
> did you find it?!

Actually I have no idea if and where it is documented. I probably just
picked it up from the list. It's not in the reference manual afaik.

Quote: thijskoerselman@gmail wrote on Sat, 28 October 2006 20:42

> Actually I have no idea if and where it is documented. I probably just

> picked it up from the list. It's not in the reference manual afaik.

Ah, I found it. It's not in the reference manual but it is in Max46Topics in the arguments topic. I looked for it right there but I guess I missed it. It's at the very bottom.

Quote: thijskoerselman@gmail wrote on Sat, 28 October 2006 20:42
----------------------------------------------------
> Actually I have no idea if and where it is documented. I probably just
> picked it up from the list. It's not in the reference manual afaik.
>

Ah, I found it. It's not in the reference manual but it is in Max46Topics in the arguments topic. I looked for it right there but I guess I missed it. It's at the very bottom.


> I agree about the idea of a quiet mode. In this case though, not

> naming the pattrmarker doesn't nescessarily have to be a mistake. In

> my case I need multiple instances of an abstraction in which

> pattrmarkers are to be named dynamically. When I provide a dummy

> name, pattrmarker will give an error because that name already exists

just name it [pattrmarker #0dummy] then there is no problem...

Mattijs Kneppers wrote:
> I agree about the idea of a quiet mode. In this case though, not
> naming the pattrmarker doesn't nescessarily have to be a mistake. In
> my case I need multiple instances of an abstraction in which
> pattrmarkers are to be named dynamically. When I provide a dummy
> name, pattrmarker will give an error because that name already exists
> (see example below).

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


I misunderstood "parent", I thought it was only for pattrhub.

I'm on Windows 4.5.7. I don't see the "parent" syntax explained in the PDF docs or the helpfile. Am I possibly working off out-of-date documentation?

I misunderstood "parent", I thought it was only for pattrhub.  

I'm on Windows 4.5.7. I don't see the "parent" syntax explained in the PDF docs or the helpfile.  Am I possibly working off out-of-date documentation?

The dummy name worked well inside abstractions. Right now I am running into the same problem inside subpatchers. As far as I can see there is no way to initialize the pattrmarker with a unique name when it is not in an abstraction. Jeremy, I know I am asking much, but is there a chance for you to introduce an attribute that supresses the error message when no name is provided at startup?

If there isn't, would it be possible for me to create my own pattrmarker object that works without the error message?

Quote: Mattijs wrote on Sat, 28 October 2006 14:42

> Quote: Jeremy Bernstein wrote on Sat, 28 October 2006 14:11

> ----------------------------------------------------

> > Why not provide a dummy name and replace it? I am not generally open 

> > to the idea of implementing "quiet" modes for objects -- errors are 

> I agree about the idea of a quiet mode. In this case though, not naming the pattrmarker doesn't nescessarily have to be a mistake. In my case I need multiple instances of an abstraction in which pattrmarkers are to be named dynamically. When I provide a dummy name, pattrmarker will give an error because that name already exists (see example below). If you want I can send you a stripped version of the project I'm working on, to illustrate why I need this functionality.

> > > Another interesting observation about pattrmarker (sorry for 

> > > bugging you Jeremy): try to encapsulate a single pattrmarker. It 

> > > says that its name is already in use. Looks like the pattrmarker is 

> > > duplicated first, before the old one is destroyed.

> > This is true; for the safety of your patch, the old objects aren't 

> > deleted until the new ones have been successfully instantiated and 

> > patched. I'm afraid that this is just "one of those things".

> I see. Luckily it's not much trouble at the moment, merely slows down editing a little. I'll have to restart the patch after encapsulating.

> save this as an abstraction named 'abstraction':

> #P newex 50 50 87 9109513 loadmess name $1;

> #P newex 50 75 91 9109513 pattrmarker dummy;

> then make this into a patch, save it, re-open it.

> #P newex 163 51 97 9109513 abstraction instance2;

> #P newex 55 51 97 9109513 abstraction instance1;

Quote: Mattijs wrote on Sat, 28 October 2006 14:42
----------------------------------------------------
> Hi, thanks for replying so quickly!
>
> Quote: Jeremy Bernstein wrote on Sat, 28 October 2006 14:11
> ----------------------------------------------------
>
> > Why not provide a dummy name and replace it? I am not generally open  
> > to the idea of implementing "quiet" modes for objects -- errors are  
> > there for a reason!
>
> I agree about the idea of a quiet mode. In this case though, not naming the pattrmarker doesn't nescessarily have to be a mistake. In my case I need multiple instances of an abstraction in which pattrmarkers are to be named dynamically. When I provide a dummy name, pattrmarker will give an error because that name already exists (see example below). If you want I can send you a stripped version of the project I'm working on, to illustrate why I need this functionality.
>
> >
> > > Another interesting observation about pattrmarker (sorry for  
> > > bugging you Jeremy): try to encapsulate a single pattrmarker. It  
> > > says that its name is already in use. Looks like the pattrmarker is  
> > > duplicated first, before the old one is destroyed.
> >
> > This is true; for the safety of your patch, the old objects aren't  
> > deleted until the new ones have been successfully instantiated and  
> > patched. I'm afraid that this is just "one of those things".
>
> I see. Luckily it's not much trouble at the moment, merely slows down editing a little. I'll have to restart the patch after encapsulating.
>
> Thanks again,
> Mattijs
>
>
> Example of dummy name problem:
>
> save this as an abstraction named 'abstraction':
>
> #P newex 50 50 87 9109513 loadmess name $1;
> #P newex 50 75 91 9109513 pattrmarker dummy;
> #P connect 1 0 0 0;
>
> then make this into a patch, save it, re-open it.
>
> #P newex 163 51 97 9109513 abstraction instance2;
> #P newex 55 51 97 9109513 abstraction instance1;
>
>
----------------------------------------------------


How about if, in the absence of a name, pattrmarker generates a 

unique, but useless name (u1234567 or whatever)? No muss, no fuss? 

Remind me, are you on Mac or Win? I'll send you a quick build and you 

Am 09.03.2007 um 12:16 schrieb Mattijs Kneppers:

> The dummy name worked well inside abstractions. Right now I am 

> running into the same problem inside subpatchers. As far as I can 

> see there is no way to initialize the pattrmarker with a unique 

> name when it is not in an abstraction. Jeremy, I know I am asking 

> much, but is there a chance for you to introduce an attribute that 

> supresses the error message when no name is provided at startup?

> If there isn't, would it be possible for me to create my own 

> pattrmarker object that works without the error message?

How about if, in the absence of a name, pattrmarker generates a  
unique, but useless name (u1234567 or whatever)? No muss, no fuss?  
Remind me, are you on Mac or Win? I'll send you a quick build and you  
can try it out.

> Hi, here's a follow-up.
>
> The dummy name worked well inside abstractions. Right now I am  
> running into the same problem inside subpatchers. As far as I can  
> see there is no way to initialize the pattrmarker with a unique  
> name when it is not in an abstraction. Jeremy, I know I am asking  
> much, but is there a chance for you to introduce an attribute that  
> supresses the error message when no name is provided at startup?
>
> If there isn't, would it be possible for me to create my own  
> pattrmarker object that works without the error message?
>
> Thanks,
> Mattijs


Quote: Jeremy Bernstein wrote on Fri, 09 March 2007 12:25

> How about if, in the absence of a name, pattrmarker generates a 

> unique, but useless name (u1234567 or whatever)? No muss, no fuss?

> Remind me, are you on Mac or Win? I'll send you a quick build and you 

> Am 09.03.2007 um 12:16 schrieb Mattijs Kneppers:

> > The dummy name worked well inside abstractions. Right now I am 

> > running into the same problem inside subpatchers. As far as I can 

> > see there is no way to initialize the pattrmarker with a unique 

> > name when it is not in an abstraction. Jeremy, I know I am asking 

> > much, but is there a chance for you to introduce an attribute that 

> > supresses the error message when no name is provided at startup?

> > If there isn't, would it be possible for me to create my own 

> > pattrmarker object that works without the error message?

Quote: Jeremy Bernstein wrote on Fri, 09 March 2007 12:25
----------------------------------------------------
> How about if, in the absence of a name, pattrmarker generates a  
> unique, but useless name (u1234567 or whatever)? No muss, no fuss?  

> Remind me, are you on Mac or Win? I'll send you a quick build and you  
> can try it out.

>
> Am 09.03.2007 um 12:16 schrieb Mattijs Kneppers:
>
> > Hi, here's a follow-up.
> >
> > The dummy name worked well inside abstractions. Right now I am  
> > running into the same problem inside subpatchers. As far as I can  
> > see there is no way to initialize the pattrmarker with a unique  
> > name when it is not in an abstraction. Jeremy, I know I am asking  
> > much, but is there a chance for you to introduce an attribute that  
> > supresses the error message when no name is provided at startup?
> >
> > If there isn't, would it be possible for me to create my own  
> > pattrmarker object that works without the error message?
> >
> > Thanks,
> > Mattijs
>
>
----------------------------------------------------


Quote: Mattijs wrote on Fri, 09 March 2007 14:37

on mac today until 18:00 +1 GMT, to be precise ;)

Quote: Mattijs wrote on Fri, 09 March 2007 14:37
----------------------------------------------------

Oh, please mail to mattijs@smadsteck.nl if you are not posting on the forum. The address I used to register is no longer valid.

Pattr - Parallel and independent hierarchy