I'm on a Mac, making a subpatcher (let's call it PATCHERNAME.MAXPAT) in Max that can be used as an external in another "Master" patcher – but I want the contents of the subpatcher to be hidden to an end user.

If I make a patcher and then build it as a Collective, this creates a stand-alone application (called PATCHERNAME.MXF) that can be run (in Max).

However, if I try to load PATCHERNAME.MXF into the "Master" patcher as an external (by typing either PATCHERNAME.MXF or just PATCHERNAME into a new object), I get the message "newobj PATCHERNAME: No such object". It's not a file preferences problem... It's not a cross-platform problem...

I'm on a Mac, making a subpatcher (let's call it PATCHERNAME.MAXPAT) in Max that can be used as an external in another "Master"  patcher – but I want the contents of the subpatcher to be hidden to an end user.

However, if I try to load PATCHERNAME.MXF into the "Master" patcher as an external (by typing either PATCHERNAME.MXF or just PATCHERNAME into a new object), I get the message "newobj PATCHERNAME: No such object". It's not a file preferences problem...  It's not a cross-platform problem...

I'm on a Mac, making a subpatcher (let's call it PATCHERNAME.MAXPAT) in Max that can be used as an external in another "Master"  patcher – b

problems-loading-a-collective-as-an-external

if you want that abstraction to be included in mxf file

than paste it into main patcher as patch.

patcher is not external
what you describe is abstraction
if you want that abstraction to be included in mxf file
than paste it into main patcher as patch.


Thanks for the reply but it's the opposite that I'm trying to achieve. I want to be able to use the mxd file as an abstraction.

However, a colleague suggested a nice work-around. I've embedded the sub-patcher in a bpatcher, and made everything invisible. It's not bullet-proof, but it'll do.

Turns out that the invisible sub-patcher is not an option... All you need to do to circumvent this is to open the main .maxpat file in a text editor and delete all the lines that say

So, I'm still looking for a way of sending someone an abstraction to use in another Max patcher without them being able to see the contents. Is this possible?

Turns out that the invisible sub-patcher is not an option... All you need to do to circumvent this is to open the main .maxpat file in a text editor and delete all the lines that say
"hidden" : 1,
and save it. This reveals everything...

So, I'm still looking for a way of sending someone an abstraction to use in another Max patcher without them being able to see the contents. Is this possible? 

It really depends what in that patcher is.

pcontrol object can load mxf fies, but they open as separate patchers, without inlets and outlets.

If you provide more infos about that patcher that needs to be hidden,

It really depends what in that patcher is.
Do you need to embed some externals ?
pcontrol object can load mxf fies, but they open as separate patchers, without inlets and outlets.

If you provide more infos about that patcher that needs to be hidden,
one coud make some suggestions


Attached is a very simple example of a patcher with one audio inlet, one audio outlet and two control inlets.

How can I share this patcher with someone so that they can use it as an abstraction but they cannot see the contents?

If I build this patcher as an .mxf file, and try to use it as an abstraction in another patcher, I just get the error "newobj : abstraction_example: No such object"

It feels like I'm asking a stupid question - so: my apologies if I'm missing some basic feature here...

abstraction_example.maxpat

How can I share this patcher with someone so that they can use it as an abstraction but they cannot see the contents? 

main problem with this is that you need inlets and outlets.

mxf file format can not be used as abstraction.

you can load mxf file using pcontrol, but that is same as opening it as a file.

but anyway - mxf file can easily be turned into "normal" patch

although it offers some sort of possibilities to keep stuff more secret than

that builds mxf file without any externls embeded.

It is anyway my prefered method for many reasons.

main problem with this is that you need inlets and outlets.
mxf file format can not be used as abstraction.
you can load mxf file using pcontrol, but that is same as opening it as a file.

but anyway - mxf file can easily be turned into "normal" patch
although it offers some sort of possibilities to keep stuff more secret than
normal patch.

You need to build mxf file using line
excludeexternals true

on top of build script.
that  builds mxf file without any externls embeded.
It is anyway my prefered method for many reasons.


Problems loading a Collective as an External