let’s take a look at their patch (Spectral Mixer Teaser : http://www.puremagnetik.com/Spectral_Mixer_Teaser.zip)

1 – open the amxd file in a text editor
2 – query replace “active” by something like “bugmenot” (there is a [active]-[sel 1]-[t dispose]-[thispatcher] that makes the subpatcher to suicide if you open it).
3 – copy everything from the first ‘{‘ to the last ‘}’… paste it in max…explore a bit…try things…

you can see a subpatch that contains everything except the ui objects, and transparent connections (cmd+a to see them all).
inside the subpatcher : white background, white font, transparent objects borders/background… and everything is messed up.

that doesn’t explain why you can’t edit the patch in M4L. but you can re-arrange the patch and paste it in a new M4L device.

now let’s take a look at the original amxd file in a text editor. you can see it starts with :

[code]ampf aaaameta ptcha mx@c a‹{[/code]

if you look at a ‘normal’ M4L device, it starts with something like :

[code]ampf aaaameta ptcha{[/code]

and a mxf (max collective) file starts with

[code]mx@c Aï[{/code]

so it's like they managed to load a mxf into an amxd device... i didn't manage to find the solution yet, and i think i won't lose to much time on it since it's possible to copy the patch into a new device. but that's an interesting thing.

i really think protecting your max patch won't be possible until they decide it at C74, and i'm not sure they will. one way would be to compile a max patch into a real standalone, not just runtime+mxf. but again, i think that's not in C74 priorities.

g

But how to protect directly Max externals written in C?

Does watermarking looks overdimensioned to protect a max external, or not?

unique machine licence // unique user licence // etc…

you can have a look at the tap.tools, they are “protected”.

if you wrote a very impressive external, it can worth it.

g