“I think sometimes people say, boy, I just spend a few hundred dollars on this app, I’d better build something amazing right away!” – Peter Kirn

When somebody ask me for a vj gig i decided to make my own little patch. I didn’t have much time. I had two alternative. To learn in short time a vj softaware or to design my own tool.
I chosed the second option and it was the best alternative.

booking my flight!!

@Basement Hum, that’s a good point… you know, it does make me think a lot about how this really needs to be integrated into the client. Would love to see that in a future Max. :)

That’s interesting, thanks.

Next I’m hoping to find a sensible way to intelligently resolve conflicts in max’s JSON files.

Here’s the scenario that causes a problem for the default diff/merge mechanism git uses (i’m pretty sure the same is true for svn etc also).

There’s an origin patch. Two users make parallel, but different edits to the patch; eg. they both add a different comment box and type something into it. One of those users tries to merge the other’s changes into his repository.

Git can’t differentiate between the two comment boxes that have been added to the different versions. Instead it sees them as a single box with conflicts on the lines that describe diverging attributes (which are usually the text attribute and boundary box coordinates). Of course the desired behaviour is that both comment boxes are incorporated into the merged file, and that no conflict is raised.

I think the solution might have to do with creating a custom merge(and or diff) driver for git that honours JSON structure. Javascript routines that do something similar are floating around, like this one: http://tlrobinson.net/projects/js/jsondiff/.

It may also be necessary to enrich the id attributes of max’s objects to enable the merge routine to be able to reliably identify independent objects. Perhaps a pre-commit hook to a script could be added, that appends a timestamp after each object id, this would be a kind of birth date of the object (max leaves appended id data intact when you re-save)–then the merge driver would inspect these id’s to determine whether or not to treat objects in parallel edits as identical, or separate.

If anyone has any thoughts, clues, suggestions about how to approach this, please let me know, Thanks. (apologies for cross posting to the c74 forum too!)

The best thing to build at first is usually something that takes basic MIDI input and does something to it. Audio is always tougher. So you could, say, take joystick or HID input and have a nice little controller app.

Thats how I felt when I started learning PD, I tried a few times, even uninstalling. Just start with small patches, simple oscilators or random sequencers, timers,and simple tutorials. Then just learn to modify those small ones, and it’s easy to see how your patches functionality and your knowledge grows