How to export finished patches,...

coffeencigs's icon

Hey..

so now i got a few patches i want to export and share with the world, but i dont want people to be able to sneak inside...

i build those patches on windows.. but of course steve job's children should be able to use them too.. so i cant export them as .exe ... build a collective?

thanks

jvkr's icon

Quote:but i dont want people to be able to sneak inside...

For your information, there is no way of preventing this, even after having built a standalone. Just try opening opening a collective with a text editor.

Collectives can be shared cross platform. But maybe you don't feel anymore like sharing knowing the above...

seejayjames's icon

Must put in my two cents on this to Cycling: will there ever be an option to have the .mxf encrypted when you build the collective? This continues to be a headache for me with an app I built where the client wants the patch protected. I want other people to start using the app and give me feedback so I can make it better, but without protection, it's not yet an option.

It's not an issue with keeping the app tied to one machine or only accessible with a serial number, there are commercial apps that can wrap the program and manage the access, which is our plan. However, *none* that I found will allow the .mxf to be encrypted during the process, without substantial custom coding that sounds pretty complex... scramble the .mxf first so it's uncopyable, then at runtime, your .exe calls a special function to de-scramble it (using a code from a protected memory space), and when you close, that temp file is destroyed. It's probably fairly simple once you know how to do it, but there are a lot of steps that would be needed... how to scramble? ASCII shifting mod 256? When does the .exe call your descramble function, and can it even do this? How to ensure the temp de-scrambled file isn't accessible, and is destroyed upon close?

I'm a rabid fan of Max, it's the best environment ever, but this aspect is really holding it back, in my opinion. Sure it's nice to share your work, I'm all about open source, but you should always have the option to keep it protected... ideally it should be easy to do, and included in Max itself rather than a complex workaround outside it that everyone needs to re-invent each time... with varying results. Being able to protect your very hard work from someone who can so easily copy and re-create it is absolutely essential for great new apps to be developed... like Photoshop, Dreamweaver, or Max itself. These would not exist in their current, highly sophisticated forms without protection.

I know it might be a royal PITA to program this in, so if it raises the cost of Max (or better, is available as a paid add-on) I'd gladly pay for it. This way people that don't need the service wouldn't pay anything extra.

Along those lines, I'm assuming some kind of protection scheme is in place for Max apps like Radial and Cyclops, is there any way you could share how that was done? If it's proprietary I understand, but if there's a technique that we could use for our apps, I'd love to hear it.

For the other question, you can make a mac app/standalone, but you need a Mac with Max on it to build it. Then Steve Jobs' children will be happy too.

coffeencigs's icon

i dont get paid for making patches, and i dont want money for my patches...
so i'll share them anyway..

but in cases like seejayjames mentioned... this lack of beeing able to protect your patch is fked up

Roman Thilenius's icon

if patches could be protected, people could copy work by
others which is freely shared by the original authors -
and protect it.

so if you start to make it easily possible, soon anyone
had to use it and then sharing is over.

i´ve always found it funny to steal and copy and from others
from time to time - or see my own code abused somewhere in
another patch.

jvkr's icon

Stealing code for me is not an issue. I don't even steal code from myself. If I need to create a solution that I used before, usually I find myself doing that from scratch. Mostly that is quicker then copying code and adjust it to the new situation (which is always slightly different anyway). What I do steal is approaches, but such things can be borrowed from any software. In that sense everything can be reverse-engineered. Of course, there can be a 'secret' filter definition or something in your patch, but there are sufficient methods to hide such things.

seejayjames's icon

Roman, that is a good point, it would be easy for others to take what you make freely available and protect it. But that's the same as with many kinds of media and tools. So if you make something freely available you are in one sense accepting this fact. Probably we don't want someone to take what we've done, re-package it, and make money off it... but if it's out there with no protection or some kind of copyright, and no way to track what happens to it, this is how it is.

If someone were to collect all the great bits on the Forum and put it all together into a killer app and sell it, probably it would bother some people. That's understandable, especially as this person may be acting less like a programmer and more like a packager/marketer. But that's a skill in itself, and plenty of jobs out there require exactly this.

We get inspiration from a lot of sources, and even if we significantly modify what we find, we may come up with something that we might never would have on our own, without using that one important bit--that someone else created--which made us think, Ah-ha! Now I can make THIS.... Who "owns" the intellectual property of the resulting app? It might be hard to say in some situations, but generally you'd have a strong case that it's yours, and that the inspiration was gathered from freely-available sources, therefore you're not infringing upon anyone else's work. Gray areas for sure, especially with software that relies on so much prior work and so many prior ideas, so that's why these discussions are important.

I don't think sharing will end if this protection were a reality. We've collectively posted thousands of patches on here, and I think we generally do it just because we find it fun and interesting, or maybe we want to show an idea or a trick we figured out. Most patches are nowhere near sellable, and that's totally fine... some take 10 minutes to make, others take a few hours, some take longer. But if you spend six months on something that you think is great (and the programming is only one part---there's the UI, the help files, the picky layout details, the media, the presets...) you should be able to protect this hard work and sell it, if people are willing to buy. Hopefully you'll provide a free demo, or make it shareware/donation-only. But if you want to require payment for it, you should be able to.

Consider those really helpful, paid externals out there that people create and sell, even for a small price. Many people are willing to pay for them, because they're useful, and we understand that charging for them will help fund the programmers (at least a token amount). This kind of hard work should be rewarded if that's what you, as the creator of the valued tool, want. The considerable time you've spent learning is worth something, just as it is with professional programmers.

Another common example: a slick Flash banner ad for a website. That company paid someone to make it, so most likely it's not available to download and edit. Maybe we don't agree with this, but the protection available makes it worth it for the company to invest money into its creation. This creates jobs for creative people, which is a good thing. And yet there are countless websites where users freely share flash projects and code snippets, and I don't think they're disappearing anytime soon.

I bid on a freelance job where the client wanted a remote-monitoring system for user webcams and their desktop. They wanted it in Flash, but I thought, hey, jit.qt.grab, jit.desktop, jit.net.send, a few controls, and voila. I put together a demo patch (attached) that did most of what they asked for and sent it off, just to see what they thought. They liked it and were impressed at what this unfamiliar "Max" could do. But they didn't choose it for the project... partially because they didn't know Max, and wanted to be able to manipulate the app themselves... but also because of the lack of protection available. It was intended to be part of a larger application in which they were planning to invest considerable money. So not being able to protect it was the deal-breaker, and I can't blame them for their decision.

This is unfortunate, in my opinion, as it could have helped get the word out about how useful and powerful Max is. More people and companies need to know about the amazing tool we have here, and that there is an alternative to the other platforms. They need to know that they can invest money in programmers like us to make applications in Max for a variety of their needs, and that they can own and protect that intellectual property. With more of these apps out there, more and more people will start asking "What is this Max/MSP? It looks awesome!"

The last thing I want to do is bother anyone at Cycling or the other forum members. Maybe I have already, and if so, I apologize. For me, being able to protect our apps is not just about making money for ourselves, it's also about having a platform whose products can be safe from hacking. The vast majority of what we do we're probably willing to make freely available, and that's fantastic. We do it because we like it and we want to see what other users think, and to learn from different approaches... in my opinion, the best part of these forums. But if we want to take applications to the next level, and to get more of them into the professional world, there needs to be a way to protect them somehow. Whether this protection scheme is included in Max or accomplished by a different means, if it works and it's simple, we'd have it as an important option.

Roman Thilenius's icon

the 110 militia apparatus is in a long term struggle with
the open source believers, which are trying to install a
system of peaceful coexistence of commercialised and non-
commecialised code (and information) on my planet.
(i never told you, but this planet you are on belongs to me.)

i do believe that it can be right to do all of it: steal,
buy, sell, and share, side by side.
there is no contradiction in doing all of these things.

but that does not make the two worlds a peaceful coexistence
like "open source" suggests it.

our alien investigation at 110.brainfactory has found out
that sharing remains useless unless it is meant to become
the market with no other markets.

on the long run, giving away code and information will only
help to raise or hold the profit ratios of those who sell,unless it is made secure it will not

you might say it is not relevant, it does not apply to the
max world.
but it might be a good move to use max as training camp
for the future 110 market organisation.

on my planet.

-110

.

lewis lepton's icon

sorry if i am re-living an old post, but this has come up for me, being that i want to protect my program because i plan to sell it very soon, and would like it if no-one could take a peek inside.

in many more ways than one this issue is a catch 22 situation. people dont care for protection of patches and others do. some dont care, others do.
the one thing i dont get, is why make an application build mode in max, without having a form protection for it. it does seem silly to have that option, and not be able protect it.
i think the protection feature should come in. mainly because that now pluggo is no longer available for max 5 builders to build plugins for all formats. people will resort to building standalone applications instead. so this option should be allowed, or at least the option is their for people to use.

i do get that max could be used as a 'starter' to building tools and getting in the mode of building. then move onto say, c++ or something else.
but, why only use it for a starter and move on to another program to build tools. max is a powerful program that does take a long time to learn and master, so when you have mastered, does that mean you should move on?
no.
you make your skills better in max and soon enough would like to market something off for others to enjoy. the only main difference is that you are getting something out of it for your troubles of building it for many-an-hour, rather than it being for free.
this is just plain and simple human choice, there needs to be choice for people, no matter who you are.

i am not arguing at anyone who may disagree, i am just sharing my views on what i think would be good and better for the max community, who would like to take their max building to a bigger audience.
thats my view, which i do hope along with everyone else who has said that they would like this feature, that in some way, shape or form does make it in.

aye...

lewis g. edwards

Gregory Taylor's icon

No one's stopping you from creating your own way to encrypt patches. But that doesn't mean that there's necessarily likely to be any help from Cycling '74 in making it possible to hide things for profit.

lewis lepton's icon

aye true, who would help someone hide material that would give them profit. i do understand.

but in the end, all i am saying is just having the option would be good. thats it really...

Tj Shredder's icon

In principle I would agree, easiest, though not really encryption, would be if the compressed format could be read by the runtime, and simply that format in addition as an option to save to disk or into a collective. The basic code is in Max already.
This would not prevent a knowledgeable person to dive into your patch, but it would make it as difficult as it was in Max 4.x

You might ask Stefan Smulovitz about his experience with the Kenaxis patch, well ported to Max 5. I doubt that the theoretical ability to unpatch it does have any effect on his sales. His patch is complex, and if you place enough levels of subpatchers into it, its a pain get a running version together. I'd say no matter how complex a patch is, its easier to rebuild it from scratch.

Your customers are those who don't want to patch and certainly don't want to hack.
We are not talking about copy protection here, which is a completely different beast, thats why I guess that the customers you envision are willing to pay for your work anyway, why bother? Don't hold back and wait for external solutions, just throw it into the public and see whats coming back...
(If you cultivate some paranoia, create a personalized version for each customer with the serial built into the patch, and you will know where the leak is if your patch unexpectedly appears in the wild on P2P sites...;-)

Stefan

seejayjames's icon

One thing you can do for your .mxf is to use a ton of abstractions rather than subpatches. Each abstraction is listed separately in the .mxf and there's a bunch of "garbage" (no doubt is necessary, but won't paste into a patch correctly) between each listing. With enough of these, and enough connections between them in order for your patch to work, it would take quite a while to reverse-engineer... lots more pasting into new patches, then figuring out how they're supposed to connect together. The danger is when you have pretty much everything in one big patch, which is one long entry (including subpatches) and can be copied/pasted in one step. Also sends and receives will still work after pasting into new patches, but of course your connections will be gone, so these are better in that regard.

So at that point, the issue becomes locking your app to a specific machine. I'm sure there's a way to do it yourself, but there are plenty of commercial options for this as you're probably aware, and would save a lot of headaches. There may be free apps available for this too.

If Max Runtime could open patches from jit.textfile, we could make our own text-scrambling routines without too much trouble: jit.op @op +m, have four of these (32 bits worth of combinations) which iterate through the text on a per-character basis. Kind of like a spinning bike-lock... a Cycling lock? Oh man, that was terrible..."Good night everybody!"

Though I'm sure there's a very good reason the Runtime won't do this...any ideas? It still wouldn't be able to save the patch, just open it...you'd make an "opener" patch that would access and descramble it, with a unique code for each copy. Though I suppose the descrambler patch could be hacked, and round and round we go...

volker böhm's icon

> One thing you can do for your .mxf is to use a ton of abstractions rather than subpatches. ...
> With enough of these, and enough connections between them in order for your patch to work,
> it would take quite a while to reverse-engineer...

quite a number of people who offer their standalones for sale, seem to rely on this approach.

but a word of caution, if you know how to do it, this takes absolutely no time, regardless how many abstractions or externals are used. i haven't seen a standalone or collective recently that couldn't be re-converted into its maxpat components within seconds.

> So at that point, the issue becomes locking your app to a specific machine.

if you can't prevent people from parsing your standalone into editable max patches, all efforts to make a copy unique to one machine usually fails, of course.

to make all this halfway secure you probably have to invest a lot more time and energy.

> If Max Runtime could open patches from jit.textfile, we could make our own text-scrambling
> routines without too much trouble

i would look into java and mxj for these things.
decide for yourself, if it is worth the effort.

v

daffne's icon

Thanks for the help)) highly appreciate