How to prevent M4L device from being edited?

could probably be done with thispatcher scripting, too?

(I personally only go for freely editable devices, but that's beside the point ;) )

@Wetterberg: how about non-free, but editable devices?

I feel there's something wrong about a Max for Live device that you can't edit. I'm working on a commercial release, and wonder how much piracy is a concern. Copy protection is a PITA, and I'm hoping that a fair price is better copy-protection, but I guess we'll see.

I agree, it is totally against the whole point of M4L to prevent editing now. But this also stops developers to spend time on develop commercial devices.

I guess, the only way now is to release under creative commons licence or something similar or ask for donations from users.

Asking for donations is a non-starter, in my experience. I've had over 10,000 downloads of my devices but I never got a donation when I had a PayPal donate button on my old site. (which is why I left it off my new site, frankly)

I had the downloads hosted on maxforlive.com and the documentation on my site, so I probably didn't see as much traffic on my site, but still...

I like the idea of free devices and try to make mine so when I can, but it's not always sustainable. Devices don't bring in enough traffic that you can make money based on advertising. I've been looking at Gumroad, and it seems like a pretty reasonable model.

This seems to be a recurring topic on the forums, too: "I like Max, is there any way I can get paid so I can spend more time in Max?"

The couple of commercial devices I've checked out have used a kind of makeshift method of making all the objects transparent and stacking them on top of each other. Seems pretty time consuming and, ultimately, ineffective since someone willing to put the time in to untangle it all can eventually make the code readable.

I'm like Wettergberg and only deal with editable devices, paid or free. If I like a device enough to use then I'm also going to want to know how it works under the hood and be able to make any modifications I want. To me that's one of the whole points of Max and M4L.

I recently asked a dev on the Ableton forum who was plugging his devices why he chose to use (the aforementioned) copy protection scheme. His reply was that making the insides (easily) available would take away "the magic" of how the device works. My response was that for some of us übergeeks the insides are the magic!

Exactly. I have definitely modified devices to fit my own purposes, and hope that there are others doing the same. Moreover, I don't want to have to track down bugs in obfuscated code. (doubtless they have a script they run it through or some such, but it still seems like a lot of hassle for the developer)

I have toyed with the notion of having two price points, the cheaper with obfuscated (or at least not cleaned-up...) code and the slightly more expensive version with thorough commenting, clean layouts, etc.

There are a lot of people who don't care about how their devices work--or at least enough to warrant a section in Ableton's Max for Live FAQ--but there's definitely things you can learn from other's devices.

Clean code takes more time, and I wonder if people would be willing to pay a small premium.

If you want to sell something you made in M4L, the only real way of doing it is to prototype it there and then re-code it as a VST or Audio Unit. You're essentially selling a script which requires *a lot* of external dependencies to run so there's really no guarantee to the end user that your patch is even going to be fully functional 6 months down the road. It's also not very comforting knowing that the developer isn't dedicated to his/her device enough to put in the time consuming effort to code it in C, so there's already that demonstrating that you'll most likely not keep it updated.

You have to go the extra mile to get people trust you with their money.

I'll agree with the last sentence, and say that the paragraph before that is sad if true. (the more compelling argument to me is that there is a considerably bigger market for VSTs than AMXDs) I tend to view Max as an interpreted language, the sort of thing that people outside of its community are skeptical about.

Each language has its strengths, weaknesses, and idiomatic usages, and I guess it all depends on what you're trying to do. I've done a decent amount of C++ DSP stuff, but I still prefer Max for the flexibility and expressiveness it provides. C/C++ is great for efficiency and low-level control, but it's not nearly as good as Max for exploring, especially when you factor gen~ in. Hopefully gen~'s code generation will close some of this gap. There are still some things that C/C++ is helpful for, but Max's capabilities continue to grow.

I'd add that I regularly use abstractions of mine that are 10+ years old, so I don't think that it has to be that way in Max. I don't believe that coding it in C necessarily shows more effort; I think it sometimes means that that effort just goes to a different place. (like waiting for that compile to finish so you can load it into the AU tester) YMMV.

Anyways, I'm very far afield from the original topic.

what is the copy protection scheme that @stringtapper mentioned?