LFO everything 1.6 ....... faster, simpler, cleaner !

[mr.ergonomics]

Cargo-cult patching is and remains a fact of life. I shudder to think how much of my crap patching might be out there somewhere [happily, I fully expect it's not much].

Beyond questions of honor or integrity or honesty or credibility that may be in play, the more chilling possible effect has to do with how users here may feel about creating and sharing patches that - despite common and regularly used things like Creative Commons and the canons of plain old regular politeness - someone with fewer scruples can simply package and resell to the credulous and uninformed with no apparent ill effect. In a community like this, the ripples of that behavior spread a lot farther and a lot faster than a single bad act. *That's* what I'd be more generally concerned with.

good comment

[julienb]

indeed.

[stringtapper]

LFO 1.52 in progress

Great news! I assume it includes an appropriate credit to the author of the track/device/parameter chooser subpatch?

[julienb]

LFO 1.52 in progress

Great news! I assume it includes an appropriate credit to the author of the track/device/parameter chooser subpatch?

lol
you want your name too?
man... please.

[julienb]

another (funny) idea: repatch ALL.
maybe everyone let me quiet

I can do that.
I didn't steal (115th time I wrote that) but I can rewrite all
really

what do you want? JS ? C externals? python ?
it could be interesting for all

[[nis]]

LFO 1.52 in progress

Great news! I assume it includes an appropriate credit to the author of the track/device/parameter chooser subpatch?

lol
you want your name too?
man... please.

I'm speechless...

[mdk]

I didn't steal (115th time I wrote that)

I think the only thing that can prove your side of the case is to do a diff of the json and show that the similarities claimed to exist dont actually exist.

http://en.wikipedia.org/wiki/Diff

[Seppe]

Hi everyone - I'd like to echo mr. ergonomics' suggestion and ask Julien and Edward to resolve this issue privately. This forum is not the right place, and sentiments are getting very negative.

I don't know David. Julien apparently is an Ableton certified trainer who appears to have committed plagiarism. He doesn't want to defend himself in an adult manner and people asking questions about this are labeled "bored with life". So we should all look the other way and trust that everything will be alright?
I think it is a good thing if a community reacts in a civilized way to things that go wrong in that community. So far, the negative sentiments seem to come mainly from Julien I must say.

[emajcher]

I didn't steal (115th time I wrote that)

I think the only thing that can prove your side of the case is to do a diff of the json and show that the similarities claimed to exist dont actually exist.

http://en.wikipedia.org/wiki/Diff

A Diff won't quite work because he copied my module and placed it into his patch so the position of the JSON code is different. If you look at the JSON code though you can quickly fine the objects from my patch in his code where some are identical, others are functionally identical but have had minor visual tweaks to hide the transgression. As others have noted, just opening up the patch you can see the similarities and how he has made minor tweaks to attempt to hide things, but the patches still remain the same, even patch cords line up, which we all know for that to be a coincidence is completely unlikely in a environment like max, yet alone objects with the same name have the same object id (which is generated by max). All that aside, there are 2 obvious different styles of developing in the patch, the persistence patcher (which I wrote) is very modular, containing a lot of sub-patches and consistent naming conventions, the rest of the LFO is one big patch with no sub-patches (not sure how scalable that is going to be over time).

At this point I am almost confused with the continual denial, the evidence is conclusive.

[mdk]

A Diff won't quite work because he copied my module and placed it into his patch so the position of the JSON code is different.

a decent diff tool should show you matching code sections regardless of location.

http://winmerge.org

im sure there are many other tools for analysing source code similarity.

[mdk]

With OO related stuff this method would become problematic anyway since you're basically comparing 2 files.

?

In this case you'd also be looking for the existence of specific code blocks from 1 file in the other, not merely differences between 2 files.

thats what I said and thats what you can do with diff tools, at least in the ones i've used (eclipse, winmerge, windiff among others)

try it. it works

and of course there are tools to just show common lines, e.g.

http://ss64.com/bash/comm.html

[emajcher]

A Diff won't quite work because he copied my module and placed it into his patch so the position of the JSON code is different.

a decent diff tool should show you matching code sections regardless of location.

http://winmerge.org

im sure there are many other tools for analysing source code similarity.

Why bother? The best thing that could happen for him is he finds some inadequate tool that shows no similarities, or it can be argued that I went out of my way to find a tool that did find some, making it subjective. If we forget the fact that the patch and sub-patches in the module are visually identical (except for minor tweaks where he removed my initials) including number of objects, their positions and lining up the patch chords. The exact structure of the patches and sub-patches match.

If we take what we know about max, the true randomness and different styles inherent in building a patch, there are sub-patchers like persist_track, persist_device and persist_parameter that have the same name (amazing coincidence) and unique object id (only visible in the raw json code) which is generated by max, hitting the lottery seems more likely. Furthermore, those sub-patches, like persist_track do not even have visual differences, they are duplicates of one another in every way, no effort was made to change them at all because they didn't contain my initials because they were embedded in the patch, not external modules. My code was uploaded to http://www.maxforlive.com in July of 2010, his code appeared last week. I am confident you will not find my code anywhere else, it was way more of an interesting problem for me at the time that I felt was a challenge to solve.

At this point I suspect he will never admit to lifting the code, I have tried to resolve this offline with him and he continues to be obstinate, never directly addressing the similarities I have outlined, never giving me credit. He continues to accuse me of being jealous (which frankly makes no sense). I think he will continue to release new versions at a very fast rate until he can remove the visual similarities; changing the actual code will probably be a little troublesome, while it is not rocket science by any means (and I never claimed it to be), the code to get it right was very fiddly and took about 10x's more work then the LFO part because of all of the idiosyncrasies when interacting with the max api when a live set is being loaded (which I think we can all relate too). My initial intention was not really to develop the LFO but develop the persistence object so I could re-use it in other patches I make.

[mdk]

Why bother? The best thing that could happen for him is he finds some inadequate tool that shows no similarities, or it can be argued that I went out of my way to find a tool that did find some, making it subjective.

if thats what you want to believe, then fine. i was just trying to suggest a technical means of showing similarities. after all a max patch is just json data.

for me that would be a far more convincing case than anything else, but then again, im a programmer

[emajcher]

Why bother? The best thing that could happen for him is he finds some inadequate tool that shows no similarities, or it can be argued that I went out of my way to find a tool that did find some, making it subjective.

if thats what you want to believe, then fine. i was just trying to suggest a technical means of showing similarities. after all a max patch is just json data.

for me that would be a far more convincing case than anything else, but then again, im a programmer

I am also a programmer by trade, I have used windiff and the merge/diff tools in Eclipse (not quite daily, but weekly) and I have found tools to be an approximate at best. Even when attempting to diff/merge files that are only off by a single version between 2 editors, obvious similarities are thrown off by an empty line and take a visual inspection to merge.

It might be possible to diff only the modules, I am not sure the impact of freeze/unfreeze in max and if that changes the ordering of the json code.

I can certainly take it that far, but opening up the patch and the 3 layers of sub-patches are virtually identical, not sure why much more evidence is needed though, but as I have stated, every object in the 3 layers of abstraction has the same name (patcher objects) and same object id in json and same exact patching sequence and functionality. How could patch chords match up in 2 objects yet alone 20?

[mdk]

Even when attempting to diff/merge files that are only off by a single version between 2 editors, obvious similarities are thrown off by an empty line and take a visual inspection to merge.

fair point, its not a rare occurence.

It might be possible to diff only the modules, I am not sure the impact of freeze/unfreeze in max and if that changes the ordering of the json code.

good question. i know what im trying tonight

also another interesting question which this situation raises is which licenses are appropriate for this kind of work?

I've read that the Creative Commons recommend *not* using their licenses for source code, but is a max patch source code?

personally I would say it is and would probably use a standard license, BUT, if a CC license is strong enough to protect a max patch then it seems like it would be a more 'recognisable' license to people who use max. Im guessing that a lot of max4live users will have come across CC at some point but relatively few would know anything about source code licenses beyond a rough idea of the GPL or something.