PureMagnetik just released a suite of M4L devices commercially: http://www.puremagnetik.com/index.php?option=com_content&view=article&id=259%3Amax-fuel-the-first&catid=94&Itemid=175.
Although you still must have Max For Live, apparently they used some sort of workaround to prevent editing of the devices. Any idea how this could be done?
-Zach
my guess would be bpatchers. do you have this pack? what does it say when you try to open it?
iam not really impressed with the patches they have..
most of the things they have are on maxforlive.com for free.
I do not have the pack, but am interested in developing devices commercially and am eager for Cycling/Ableton's promised announcement on locking devices (although, there would have to be a M4L runtime for me to feel good about selling stuff).
If they use bpatchers, what's to keep one from just opening the source file separately?
I missed when Cycling/Ableton promised the ability to lock devices - any pointers to when/where that was made?
Yeah I missed that one too.
-A
lmao. Not that I would purchase anyway, but how good would you feel about actually purchasing a device that is basically a hack?
http://cycling74.com/products/maxforlive/
Scroll down to the bottom: "The first release of Max for Live does not prevent users from opening Max devices. This is likely to discourage selling devices for the time being. Our plans for paid and free content distribution will be announced in 2010."
@zach - thanks, I had never seen that before (or maybe it's new...). Andrew?
It's been there forever.You all know we never announce things in advance, perhaps we need to stop announcing possible announcements as well.Apart from that I have nothing to add.
-A
Andrew, I think there's nothing wrong with stating your intentions for a product. I'm not holding my breath for the announcement, but it's nice to know when purchasing Max For Live that it could potentially be used for commercial development in the future. Of course, this would really require the release of M4L runtime, not just the ability to lock devices.
Anyway, back to the original topic. Does anyone have an idea of how they did the hack? I would think they would just detect whether the patch is in presentation or patching mode and immediately switch to presentation whenever it's in patching. However, I'm not aware of a way to do this with [thispatcher] and if they used an external or JavaScript, couldn't one just delete it from the device folder?
The device contains code which checks to see if it is running inside MFL as a plug, and if it is not, it closes itself using the dispose message to thispatcher.
I suspect this is the last bit of code which got added to the device
:)
-A
Interesting, so I guess a clever person might be able to delete those objects from the file in a text editor. Although, I've never looked at .maxpat's that way so not sure if they're compressed.
Can you detect if it's running inside Live using live.path?
following up on Andrew's note, if you open any of the amxd files in a text editor you can clearly see the code he's talking about:
if(!max.isplugin){this.patcher.dispose();}
The interesting part is that if you change even 1 character of that line of code, the patch will crash when loaded. I don't know if MaxMSP or Live or Puremagnetik's code does a byte compare on the size of the file or something but it doesn't seem editable.
Anyone know why the patch crashes if you change anything?
I also wondered why patcher window is closed automagically the same way when being converted to .maxpatch (amxd header is stripped and all embedded content is omitted)
It was because of wclose message. Not so bright. Just punish people for stealing your code and violating your draconian EULA. Why should you muddle their brains? )))
I would also like to know how one can embed .js and .png files into .amxd
It was done the similar way .mxf packages are built
We are missing something like Ableton's secret .alp packager, aren't we?
adamribaudo, you shouldn't edit amxd files, there is checksum or something
I believe that all .js, .png, and sub-patches are included in the .amxd file when you "freeze" it. That's all you should have to do.
Don't need to deal with .alp's unless you want to install your patches into other people's libraries.
In fact the .amxd file is 95% text. You can copy it and paste it into an empty patcher. Most elements are made very small, hidden and placed at location 100,100. In the Veer device there is a sub-patcher where all the action seems to be going on. This one wouldn'd open. I don't know if I will sort this out any further.
I don't get the rationale behind this policy of PureMagnetic. There is no copy protection and you can read the contents of the .amxd file if you really want to. One of the best uses of these devices would be to incorporate bits and pieces in your own creations. That is not as easy as it could be because opening the devive in the editor is not possible.
This is what I'm talking about
Oh, thank you, adamribaudo
I've never used freeze yet. So now I know what it is for ))
my guess is thats the line
hm.. forum strips the code..
but i mean the last line before the weird symbols start.
"if max.isplugin this.patcher.dispose"
Thanks, everyone. I didn't check this thread for a week and now all my questions are answered.
I was not aware of the freeze function. Seems it would have been enough to include any super-proprietary functioning (although there doesn't appear to be any, judging from just the descriptions) in an external and freeze it into the .amxd. Causing it to crash when opened in Max is a little silly.
You must log in to post.
