Max/MSP: it does a body good! Photo (CC Yao Chung-Han / worKingLab)

If you haven’t been following Max 5 updates, the folks at Cycling ’74 have been aggressively bug squashing. The changelog for 5.0.6 alone is exhaustive. (Via @rekkerd on Twitter, of rekkerd.org.)

Updated: Also new in Max 5, it’s now possible as of 5.0.6 to properly save your patches to a version control repository. Don’t know what that is? Now’s a perfect time to find out — it means it’ll be easier to track changes you make to your own patches, and easier to collaborate with other people. And it’s free. From adamj, on comments:

RE: the diff’ing issue I was talking about above. Timothy Place (one of the Max developers) shared this helpful tidbit:

“Since the change log is a mile long, I’ll point out an obscure new power-user feature in Max 5.0.6.

You can send a new message to Max like this (or put it in an init file):
;max sortpatcherdictonsave 1

This makes it so that the JSON files that are use by Max for saving patches will keep the dictionary in the same order (alphabetized) every time you save. If you are keeping your patches in version control (e.g. SVN, GIT, CVS, etc.) then this should make your diffs a lot more usable.”

See: Version Control and Sharing for Patching: Keep Those Max, Pd Patches in Order with Git

And in other Max news, Expo74 will be a full-blown Max conference in April in San Francisco. You still have a few days to lock in the US$295 intro price (through 3/1). On the menu:

  • C74-taught workshops for users: live looping, 3D, Max for Live, new timing objects, etc.
  • Workshops for developers: C programming and the Max external API
  • Special guest speakers, including Robert Henke — but also Miller Puckette, the creator of the original Max and developer of Cycling ’74′s open-source rival Pd.
  • An afternoon on teaching Max
  • A “Science Fair” for sharing projects
  • Field trips
  • A “Relationship Manager” – a sort of conference concierge – plus access to the C74 folks, a bit like the Apple Worldwide Developer Conference

Expo74

It’s good stuff. And the price seems a very reasonable deal for a conference.

You know, it also reminds me that some of the events around the open-source tools could be friendlier than they are. And we like science fairs. I’m not sure that I’ll be able to make it out to California in April (I’ll be there in March for the Game Developer Conference), but eager to hear how this goes.

Now that’s my kind of Max patch UI. As designed by Keith A. McMillen; photo (CC) Julian Bleecker.

But speaking of open source, don’t want to spend April at an event for a proprietary tool? Prefer the East Coast to the West Coast? Like code better than patching? Like tools that begin with the letter “S” better than the letter “M”? Want tools that make you think of supermassive black holes? Oh, April in North America has you covered regardless of what you like. One moment while I write up another post…

  • http://www.sounddesigntutorials.com SoundDesignTutorials

    Maybe attending this conference will convince me that I won't fail miserably if I try to learn Max ;) I've messed about with it a few times before and come up with absolutely nothing useful, but I can tell it's an amazingly comprehensive tool in the right hands. I may just go to hear Robert Henke talk a bit about Max for Live.

  • http://www.createdigitalmusic.com Peter Kirn

    Absolutely. The folks teaching from C74 in particular are really good teachers, many of them. I think if nothing else, you ought to leave with a different *feeling* about what you can do. So if you're invested in learning Max, this is a really good way to go if you can make it.

  • http://jordancolburn.tripod.com Jordan Colburn

    @SoundDesignTutorials.com

    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

  • http://www.sounddesigntutorials.com SoundDesignTutorials

    Cool, thanks for the tips guys! I think my biggest issue with trying to learn any tool is that I have this tendency to want to understand it all within a short amount of time. Max just shuts me down in that regard. I'll try to approach it incrementally next time.

  • http://www.createdigitalmusic.com Peter Kirn

    That can be another reason to try Pd. I think sometimes people say, boy, I just spend a few hundred dollars on this app, I'd better build something amazing right away! So even though Pd is less friendly in UI and documentation, I'd say some people feel a little more comfortable firing it up and doing something simple and manageable. You can also see how you like the basic metaphor and then decide whether you want to invest in Max or get deeper into Pd, depending on preference.

    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.

  • http://www.illuminatedsounds.com Miketron

    I started off in PD making super basic step sequencers then slowly adding onto them. Youtube can be your best friend when starting out with PD. Once I got Max5 the transition was cake, You get a lot more to play with and can build awesome GUI's.

  • Pingback: Create Digital Music » Free Software Events: Pure Data in Brazil, SuperCollider in NYC and at Wesleyan

  • http://www.basementhum.com Basement Hum

    "This makes it so that the JSON files that are use by Max for saving patches will keep the dictionary in the same order (alphabetized) every time you save."

    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!)

  • http://www.createdigitalmusic.com Peter Kirn

    @Miketron, guess that proves what I was saying.

    @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. :)

  • bufferstroker

    wow this is amazing. been looking for something exactly like this. nothing like that here in australia.

    booking my flight!!

  • http://bipala.blogspot.com/ pecta

    I like max msp jitter. Now I begin to see its limits

    "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.