Q: how to visually recognize a (sub)patcher?

[Poster]

I'm having a hard time finding out how to visually recognize if an object is a patcher or not..

the thing is that is seems that patcher titels do not always start with 'patcher' or 'p'..
hovering its in/oulets does give me the clue though, but there must be a visual clue to this?


also;
how do I open a patcher when the patch is unlocked?
I can only double click>open patchers when the patch itself is locked..

[mdk]

hold down ctrl

[hoffman2k]

There are different kinds of patchers.

The ones you see starting with "p xxxx" are regular sub patchers. These can be opened by double-clicking while in edit mode or using a window exec function from the thispatcher object.
You can go inside one of these patchers and edit it.

Second you have bpatchers. These are like sub patchers, but instead of seeing an object you see the entire patch. Its like a second window within your patcher window. bpatchers are commonly used to group together different objects into a single GUI element.

And lastly you have abstractions, like the M4L.api.xxx patches.
These are patches loaded within a patcher object. You can not edit these objects within the patch you're working. If you want to edit M4L.api.xxx you have to open the M4L.api.xxx file.
Any changes saved to this patch will be reflected in the main patch you're working on.

[Poster]

ok so I'll take it there's no visual clue then?
other than maybe recognize it's title as a patcher..

coming from Reaktor I'm used to recognize Patchers (Macros) visually..
I find it hard to get into Max' visual lingo because there seems to be very little visual hierarchy in certain areas..

for instance..
when you create an new object it can be an object or a patcher..
but both have that pale green outline..
I would at least expect a patcher to automatically receiving a different outline color..
I know I can change the color myself..
but when trying to learn how patches work, by exploring other peoples patches,
its not always instantly clear whats what.. as I said; patcher titles dont always contain 'p' or 'patcher'..

[Poster]

There are different kinds of patchers.

didn't see you're post while I was typing

thanks B!
that explained it all..

[Poster]

though opening patchers requiring the patch to be locked is weird..

there's not even a key combo for this while unlocked?

[mdk]

hold down ctrl.

[Poster]

hold down ctrl.

aah I got it..
its Cmd, on Mac..

thanks..

[cassiel.com]

The ones you see starting with "p xxxx" are regular sub patchers. [...]
Second you have bpatchers. [...] And lastly you have abstractions, like the M4L.api.xxx patches.[...]

The fourth patcher type in the trilogy is the embedded bpatcher. So, your taxonomy isn't quite right:

Named sub-patchers can be embedded - [p foo] - or abstractions - [foo] for foo.maxpat on disk.

Bpatchers can also be embedded or can be abstractions.

[hoffman2k]

The ones you see starting with "p xxxx" are regular sub patchers. [...]
Second you have bpatchers. [...] And lastly you have abstractions, like the M4L.api.xxx patches.[...]

The fourth patcher type in the trilogy is the embedded bpatcher. So, your taxonomy isn't quite right:

Named sub-patchers can be embedded - [p foo] - or abstractions - [foo] for foo.maxpat on disk.

Bpatchers can also be embedded or can be abstractions.

Yeah, you lost me on that one so clearly I'm not the most qualified person to reply to such a question.
I think I'll have to study up on the difference between "embedded" and "in a patch". I thought you could only load external files into a bpatcher. "embedding" a bpatcher in a patch, how is that different from just having it in a patch?

[Michael Hatsis]

The ones you see starting with "p xxxx" are regular sub patchers. [...]
Second you have bpatchers. [...] And lastly you have abstractions, like the M4L.api.xxx patches.[...]

The fourth patcher type in the trilogy is the embedded bpatcher. So, your taxonomy isn't quite right:

Named sub-patchers can be embedded - [p foo] - or abstractions - [foo] for foo.maxpat on disk.

Bpatchers can also be embedded or can be abstractions.

Yeah, you lost me on that one so clearly I'm not the most qualified person to reply to such a question.
I think I'll have to study up on the difference between "embedded" and "in a patch". I thought you could only load external files into a bpatcher. "embedding" a bpatcher in a patch, how is that different from just having it in a patch?

embedding a bpatcher in a patch just makes the bpatcher part of the patch it's in. Kind of like making the patch self contained. Thing is, say you have multiple bpatchers containing the same patch, but they are embedded- now you want to change the original bpatcher patch, you need to change each embedded patch.

[djod]

Still It would be visually ergonomic when a subpatch or a bpatch would be different in some consistent way.
This would make sharing and interchanging parts of patches much easier. I understand that it also like this in the "normal" Max Msp.
So this is not to be expected to change any time soon I guess. But it would make a the visual language of a to begin with rather complex and flexible environment more and better readable.

My 2 C

[Angstrom]

I also think a visual distinction would be very helpful.

What I take from the above discussion is that hardened max users tend to conform to a naming convention to help identify these sup-patches.

Am I right in thinking that the naming convention is not enforced by the app?

[emmanuel_2]

Am I right in thinking that the naming convention is not enforced by the app?

That's correct although there's no real means to differentiate between objects and abstractions, they work the same way from the user/patching point of vue.

[stefan-tiedje]

there's no real means to differentiate between objects and abstractions, they work the same way from the user/patching point of vue.

I never missed a distinction in more than 15 years of patching.
If I come across an unknown object, I read the help file. If it doesn't have one, I double click to see if its an abstraction. If it just works I really don't care...

Stefan