Pattr – Parallel and independent hierarchy

Oct 27, 2006 at 12:28pm

Pattr – Parallel and independent hierarchy

Hi,

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.

Thanks.

Adam

#28392
Oct 27, 2006 at 1:34pm

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

“pattrmarker” [1]

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

“parent::subpatch2::object”

jb

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

#87065
Oct 28, 2006 at 10:49am

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?

Thanks,
Mattijs

#87066
Oct 28, 2006 at 11:53am

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.

#87067
Oct 28, 2006 at 12:11pm

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”.

jb

#87068
Oct 28, 2006 at 12:42pm

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;

#87069
Oct 28, 2006 at 6:06pm

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.

-thijs

#87070
Oct 28, 2006 at 6:16pm

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 did you find it?!

Thanks again!
Mattijs

#87071
Oct 28, 2006 at 6:42pm

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.

cheers, -thijs

#87072
Oct 28, 2006 at 7:17pm

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.

#87073
Oct 29, 2006 at 7:50am

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).

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

Stefan


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

#87074
Oct 30, 2006 at 9:09pm

Thanks, Jeremy, will check your page.

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?

Adam

#87075
Mar 9, 2007 at 11:16am

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 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;
>
>
—————————————————-

#87076
Mar 9, 2007 at 11:25am

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.

jb

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

#87077
Mar 9, 2007 at 1:37pm

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?

That would be perfect!

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

Currently on Mac, on pc this weekend.

>
> jb

Thanks a lot!
Mattijs

>
> 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
>
>
—————————————————-

#87078
Mar 9, 2007 at 1:39pm

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

> Currently on Mac, on pc this weekend.

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

Cheers,
Mattijs

#87079
Mar 9, 2007 at 1:50pm

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.

Thanks,
Mattijs

#87080

You must be logged in to reply to this topic.