Max for Live, now into its second year, is a tool with an ambitious goal: take the custom music software creation, visual-patch-programming powers of Max/MSP, and put them inside live performance and production host Ableton Live. It’s not the only tool that allows you to hack your own instruments and effects, or customize how your music tool works – several hosts now offer scripting and patching options. But it’s both unique in its depth and breadth, and paired with the tool most popular with musicians for playing live, which puts it in a league of its own.
I personally like tools I feel are worth criticizing, and I think Max for Live fit that description. Members of the passionate Ableton and Max/MSP communities, perhaps most of all those who embraced Max for Live in their workflow, had some ideas of their own.
This week, Ableton is releasing the first batch of significant, non-bug-fix improvements to Max for Live since its release. You can try them right now in the just-unleashed 8.2.2 beta.
It’s not just about what Ableton is doing differently, though. Recently, Ableton also unveiled a set of guidelines for people making their own patches, with the hope of raising the bar and making patch publishing clearer and easier.
Daniel Büttner of Ableton offers his thoughts to CDM, including improvements to the Live API and the new “production guidelines” for people building Max for Live patches. It’s a detailed read, but I know we’ve got some hard-core patchers out there who will appreciate it. Daniel writes:
Max for Live has been around for over one year. As the community grew and produced more devices, we noticed the obvious weak points that every programmer was trying to work around, such as keeping parameter mappings intact.
A few months back, after Live 8.2 was released, we started working more closely with programmers in the community, listened to their problems and evaluated lots of devices. The two main issues we ran into were 1) limitations in the software that made it difficult to create reliable devices and 2) certain knowledge to program devices that work well in Live.
Top item on the list was the handling and persistency of mappings from a Max device to any Live parameter, which required clumsy workarounds. From what I have seen, the new persistent Ids allow programmers to reduce their Max code in a typical LFO by 60%.
live.object and live.remote~ now have an option “Save Mapping in Live Set” (Fig. 1)
Fig. 1: Save Mapping in Live Set better integrate Max for Live with your Live sets – a must for live performers, production.Another improvement allows Max devices to observe the selected_parameter in Live via [live.path live_set view selected_parameter]. Max programmers can now build an intuitive Map mode into their devices (see example code below) or follow the user’s selection, which may be useful for certain hardware integration.
The Live API can now reach inside racks, so LFOs can be grouped with Live effects and saved as a preset.
Fig. 2: “This device” is a new Max object that makes it easy to design actions around a patch being opened.A small feature that doesn’t show up in the changelog is a new Max object called live.thisdevice (Fig. 2):
“live.thisdevice reports two pieces of information about your Max Device. A bang message is automatically sent from the leftmost outlet when the Max Device is opened and completely initialized, or when the containing patcher is part of another file that is opened. Additionally, a bang will be reported every time a new preset is loaded or the device is saved (and thus reloaded within the Live application). A 1 or 0 will be sent from the rightmost outlet when the Device is enabled or disabled, respectively. Used within Max, live.thisdevice functions essentially like the loadbang object. The rightmost outlet is inactive in this case.”
The [live.thisdevice] helps timing in large devices to avoid sending values before the API has been initialized, etc.
Besides technical improvements to the software, we also want to share our knowledge with Max programmers to avoid common errors such as devices spilling into Live’s undo history or not recalling parameters correctly in a Live Set.
We’ve created a set of guidelines as a result of our own experience and known issues, a long evaluation of community devices, discussions with patch programmers.
Ableton Max for Live production guidelines [Ableton Forum]
I hope that everyone updates their existing Max for Live devices and takes advantage of these improvements as they make MfL devices a lot more reliable and fun to use.
The Production Guidelines offer lots of good ideas, including “pre-flight” checklists for technical details and presentation draw from months of experience with patches, compatibility notes for Mac and Windows, device latency, mapping, and the like. In fact, even if you don’t plan to distribute your work, it’s a great read.
Speaking of Guidelines, What About Licenses?
One issue Ableton have not handled is licensing of patches. This is likely a good topic for another article, but I can summarize my own recommendations, having talked to a range of developers and people familiar with open source software policy.
I would strongly endorse putting some sort of license document in your patches. The most important first step is, whatever your intentions for how your work is used, put it in writing. Legal agreements all begin with simply writing down what you mean; it’s when there’s an absence of information that misunderstandings most often arise. That doesn’t have to mean hiring a lawyer – thinking to yourself, then writing down, “hey, this is how I expect this to be used” is a good starting point.
If you want to release a patch to be shared and incorporated into other people’s work, the other good news is that there are licenses available that are tried and tested and do some of the work for you. That means other users can see a license with which they may already be familiar, and you don’t have to worry (as much) about the legal implications.
I understand the desire to apply “non-commercial” restrictions, but as I’ve written in the past, these provisions tend to be problematic. The problem is the lack of a clear line for what “commercial” is. If you simply don’t want others to reuse your work, you should consider traditional copyright – that’s your right as a creator. If you do want others to reuse your work and are simply afraid of abuse, the “ShareAlike” Creative Commons license and GNU Public License each require others to share any modifications you make. Those rules were created precisely because creators didn’t want to see their work appropriated by others just because you made them free.
The GPL is the license I’d recommend in this case, because it’s a mature, legally-tested license. It’s worth a read-through of the FAQ, because it clears up many misconceptions – for instance, you can charge for your (Max Patch, or other software), you can make commercial software, and the GPL requires others attribute you as well as release any modifications they make to a patch back to the public. That makes a lot of sense for the Max community, since it means the best of both worlds – other people can improve your patch, but they have to then release all those modifications, so you and others can benefit, and you can still sell your patch if you like.
Whatever you choose, I think it’s important to explicitly state your intentions. Then everyone knows the rules by which they’re playing. That doesn’t mean some people won’t disobey those rules, but I also fully expect the community to step in if they feel someone has failed to follow the rules. (We saw that happen on this site recently, of course.)
Disclaimer: these are my own opinions; I’m just adding them here as I think it’s an appropriate time to begin a conversation about this.
In the meantime:
Max Beta
8.2.2b3 is released as of this writing:
Current Beta Version: 8.2.2b3 (updated February 15, 2011) [Ableton Forum]
Changelog
** Improvements and feature changes **
(Note: Some of these changes require an update to the latest version of Max, find a download link above)
– Devices inside Racks can now be accessed via the Max for Live API
– Return tracks can now be observed via the Max for Live APILive devices and parameters can now be much more easily mapped to controls in Max devices. And devices can safely be moved within a Live Set without breaking any existing mappings. The following
changes make this possible:– There is now a simple way to observe the selected parameter via the Max for Live API, using “live.path live_set view selected_parameter.” This can be used to, for example, build a custom “map
mode” to quickly map parameters in your Live Set to controls in a Max device.
– Live objects like tracks, clips or parameters retain their identity (id nn) during operations like move, save/restore, cut/paste, delete/undo, the identity is global and can be communicated
via Max’s Send and Receive objects.
– live.object, live.observer and live.remote~ are now able to remember their target objects when Live sets or presets are saved and restored or when objects are moved within the Live set.** Bugfixes **
– Holding a note while recording a MIDI clip and stopping the transport while the note is held would result in a silent note during play back
Have a test, and let us know what you think.
And I know a number of readers have complained this site has done a poor job of covering all the developments in Max for Live patches – yeah, uh, I am human, as it happens. So do let us know if there are patches you feel are especially important. A terrific resource:
http://maxforlive.com/