Image (CC) akihiko.japan.

Max for Live is a fantastic product that treads on genuinely new ground. Its level of integration with the user interface and operation of the host reaches a new high, it comes with a rich selection of instruments, effects, and tools to use as examples, and, in combination with Max 5’s re-vamped interface, makes a comfortable development environment. It does all of this inside a host that, true to its “Live” name, provides a unique workflow.

But Max for Live also comes with some significant strings attached, and it confirms some of the disadvantages to Max as a proprietary, vendor-specific development solution for music and performance. That means that it’ll be a superb choice for certain applications, but will fail to be a viable option for others.

Technology is about trade-offs; understanding those tradeoffs is essential to making informed decisions. There’s never a “right” choice; only a right choice for you. I think the music tech community will embrace Max for Live, but it’s also important to have alternatives. The DIY creative music community likely won’t – and certainly shouldn’t – simply make Max for Live and Ableton Live its tool for everything.

In summary:

1. Max for Live doesn’t have a free run-time, which means it’s not your best option if you want to reach a wide audience with your creations.

2. Max is no longer an option for people wanting to develop plug-ins for multiple hosts, a change that didn’t go over well with all developers partly because it was only revealed after Max 5 and Max for Live.

3. Jitter output while editing is crippled in Max for Live if you don’t also own Jitter.

4. Max isn’t an open source tool, which has practical implications, including –

5. You’ll want to choose something else if you’re interested in mobile music making.

You’ll want to weigh these options when considering Max for Live, even before considering the technical specifics of the tool. You may determine it’s still the perfect tool for the job, or you may not; it should simply be part of your equation.

These aren’t entirely black and white issues, so I’ll be specific:

1. There is no Max for Live run-time – meaning Max for Live is a poor choice for deployment of instruments, effects, and controller support.

This is the most significant and fundamental issue. If you create a Max for Live patch because you want to share it with other people, you should be aware that you’re limiting your audience. Anyone wishing to use your patch will need to buy both a full version of Live 8 and a full, $295 license for Max for Live. There is no free run-time, and neither Ableton nor Cycling ‘74 has indicated they plan one in the future. In fact, representatives of both Ableton and Cycling ‘74 have told me that they expect that many people will buy Max for Live at that price for the sole purpose of running other people’s patches.

Ableton and Cycling ‘74 are businesses, and this may well be the decision that’s in their best interests. Of course, you also have the right to make a decision that’s in your own best interests. If, for instance, you get commissioned by a band to make a Max for Live patch for their performances, then you might easily pay off your own cost for Max for Live – this might be a really smart way to go. On the other hand, if reaching a wide audience is your main goal, then Max for Live is probably not your best choice – particularly if you’re interested in providing support for a hardware controller in Live. (That’s part of the reason why I hope we’ll still see OSC natively supported in Live, not only in Max for Live.)

I’m not suggesting Max for Live isn’t worth its price – I actually think it could be a fantastic investment for many users. But that’s not the point: the question is, from a creator’s standpoint, does building a tool in Max for Live allow you to reach the people you want to reach? Anyone imagining a Max-style App Store for patches is likely to be disappointed with Max for Live, at least unless Ableton and Cycling ‘74 decide to change the deployment model. On the same note:

2. Max for Live marks the end of Max as a development tool for multiple hosts – a change that, whether justified or not, wasn’t clearly communicated.

One way around item #1 is to simply use Max 5’s existing – and excellent – support for producing standalone Mac and Windows applications that use its free run-time. I expect some users who aren’t as interested in Live will continue to opt for a conventional Max/MSP/Jitter license in place of a copy of Max for Live.

Unfortunately, Max 5’s versatility as a development tool no longer applies to plug-ins outside of Max for Live. The Pluggo framework had previously provided the ability to create VST, AU, and RTAS plug-ins for Mac and Windows, covering virtually every host on the market – even Pro Tools. It was included free with a copy of Max. Correction: Pluggo was a US$160 add-on for developers, including the Pluggo plug-ins bundle, though the run-time for users was free. As noted in comments, the run-time export itself was included in Max 4.5 and later. Now, Max costs just as much as it did before, but you can only target one host (Live). Not only is there an additional cost to you, but there is to your target user, too.

Again, it’s possible this change will ultimately make sense for Cycling ‘74 and the future development of Max. That’s the decision of Cycling ‘74 and Ableton. As for what makes sense in your future, that’s a different issue. You should simply be aware that if you want to create tools for hosts other than Live, Max is no longer your tool.

I’m also disappointed in the way that Cycling ‘74 made the announcement, and I think I’m obligated to express concern about that. When Max 5 was announced in September 2007 – by which point (according to Ableton’s press release today) work had already begun on Max for Live, this is what Cycling’s David Zicarelli told the user base:

“[Pluggo] is unlikely to be ready when Max 5 is first released. If your life revolves around plug-in development, you’ll probably want to wait to upgrade until we change our plug-in support to work with the new core environment.”

(See CDM’s article from that month.) That certainly implied support was coming when it was not. There was no mention at the time that the replacement would cost money, would no longer provide a free run-time, and would only work in Live. When Max 5 was shipped, there was still no news. When Max for Live was announced in January 2009 at NAMM, there was still no mention of the status of plug-in development in Max. It was only in May 2009 that Cycling ‘74 formerly announced it was discontinuing work on Pluggo and effectively ending cross-host compatibility. Whether that decision was made earlier and not made public, or whether Cycling really did wait until May 2009 to decide what to do, this meant that a big transition for its developer base became an awkward one.

3. Jitter editing is crippled for Max for Live users.

A major selling point of Max for Live – and a significant edge it has over solutions like SynthMaker in FL Studio or the open developer tools in Reaper – is its support for video and 3D. However, this support is crippled in Max for Live if you don’t own a separate Max/MSP/Jitter license, apparently for the sole reason of encouraging you to buy Max, too. Cycling ‘74 announced only this month that Jitter’s output window will be disabled while you’re editing patches. I thought perhaps this was for technical reasons, but in fact, if you buy a Max/MSP/Jitter license, this goes away.

The good news is, Jitter output works when you’re not editing the patch, so you can still make pretty amazing audiovisual performance solutions in Max for Live for people who don’t own Jitter but do own Max for Live. However, it seems to me unfortunate that software would be crippled for marketing reasons in this way.

4. Max isn’t open-source, and projects that use it should not be considered free software.

I’m not an ideologue, and neither are most of our readers. I rely on proprietary software on a daily basis, and I believe many of these tools are worth using. Different business models and development models may make sense for different projects.

It’s also clear that many things about Max 5’s development environment are unique, and have no direct alternative or equivalent. It’s a terrific tool, and for all the complaints about price, many users get more than their money’s worth. You make an investment in something because you think it’ll pay off.

Free and open source software has its own, unique payoff, however. You can write custom objects for Max, but you can’t modify ones that are already there. There’s no direct community involvement in the direction Max development takes. You can release a Max patch with an open-source license, but only your patch is free software; the creation tool is not. That’s not to discourage anyone from developing in Max. But if your aim is making free software, you should consider using free software as your development tools. That’s true not only of Max, but proprietary software like Apple’s Quartz Composer and Cocoa APIs, or Microsoft’s .NET. Having free software development communities using largely proprietary tools would limit the potential for these communities.

Many users are likely to use both something like Max and something like Pd or Processing; that’s healthy. But just as Cycling and Ableton have worked to build their business model, the larger music tech community will benefit if people contribute to and use the open source/free software model, as well.

You don’t need to engage in philosophical arguments because of the practical reasons for doing so. One practical reason these alternatives are important:


Mobile music applications have been empowered by open-source frameworks beneath; Pd, for instance, is behind the magic of the popular RjDj. That has led to millions of people using music tools on mobile devices – and the trend is likely to accelerate. Photo (CC) Nicolas Nova.

5. Open-source alternatives are the choice you need if you care about mobile hardware.

Ableton and Cycling ‘74 software run only on desktop Mac and Windows. Without touching the question of whether desktop Linux makes sense, open source software clearly has the edge on new, emerging, embedded, and mobile platforms. Part of being truly free software is the ability to compile that software anywhere, any time. On the Linux side, that includes platforms like Google’s Android or the upcoming Chrome OS, already running on mobile phones and e-readers, and soon on other devices. But this isn’t just about Linux or free software. Pd and ChucK, among others, already work on the iPhone, and have enabled commercial applications like RjDj and Smule, mobile apps that sell numerous copies and are featured in the windows of Apple Stores around the world. You could see a Max 5 run-time for iPhone, but it’s impossible for commercial development to keep pace with everything out there.

Conclusion: choose wisely. It’d be easy for me to come out, guns blazing, advocating free software development, or alternatively, make CDM the all-Max-for-Live-all-the-time channel and ignore other options. Obviously, neither of those makes sense. I hope that Cycling and Ableton will address some of these areas going forward. I hope that we’ll do as good a job as possible on CDM covering Max for Live and how to use it. I likewise hope that we’ll work hard to develop the free software community, too. Open source doesn’t have to mean unfriendly – have a look at Processing, which I’ve found easier to teach and easier to use in my own work than commercial software. This is really about understanding the underlying models behind these tools, making the best use of those models, and making the best use of the tools for the job.

  • Have any ALTERNATIVE WAY to MAKE OWN DEVICES FOR ABLETON? Guess not. so be happy with it)

  • @m-clis: What, other than SynthEdit, SynthMaker, Pd, SuperCollider, Reaktor, ChucK, Csound, C/C++ and VST development, wiring things together with JACK, OSC, MIDI, using a different host, using no host, using hardware, using your own home-brewed solution, using the Max runtime…

    There are always choices. You can decide how good those choices are, but it's absurd to claim there aren't choices. And if the choices aren't good enough, you can make them better.

  • banned_in_dc

    @m-clis: spoken like a true xenophobic ableton fanboi.

    @peter: it seems obvious cycling was planning on dropping pluggo support from the getgo, and only led it's customers on to keep max 5 sales from being depressed. it's classic bait n switch.

    it's also amazingly stupid short-term thinking that seems to be highly characteristic of vanity businesses that don't have to make sound business decisions in order to survive. of course, cycling has never really seemed like a business, more like an exclusive club where the price of entry requires ever more lavish displays of fealty to it's vain & insecure owner. thanks, but no thanks.

    in a world moving increasingly towards openness, cycling decides the most innovative thing it can do is close itself off?

    kudos for having the balls to say what's needed to be said.

  • salamanderanagram

    it is extremely frustrating that ableton/cycling are in effect counting on outside developers to make this a product worth buying, and planning on having those developers first PAY for the privilege of making ableton/cycling more money, and then provide no way for the developers themselves to be paid for their efforts (there is no way to lock down a max for live patch, meaning anybody can freely distribute, edit, etc)

  • @banned_in_dc: I appreciate your frustration, but let's stick to the facts; there's no need for personal attacks on the developers/owners, please, or other readers.

  • Tscharf

    Well, I was thinking that MAX for Live would be how I got MAX…

    Now that I read this? Not a chance in hell. My band were considering using LIVE as our standard way of sharing files, but if I got MFL they would have to goet MFL too…and thats a lot of money…in addition to having to get live as well? Not a chance in hell.

  • Steve Elbows

    Well I've always tried to avoid Max in the past, but as Ive already invested lots in Ableton and it M4L does a lot of what I want, Ive just bought it. I like using hardware controllers that use osc, and I also want to get osc out of ableton to visualise things like matrix sequencer grids in quartz composer and unity3d, so it wasnt a hard choice to make.

    In the grand scheme of things there is plenty of downside and I appreciate peoples gripes about these.

  • Steve Elbows

    Also using the physics in unity and sending that to ableton to control audio & midi is currently filling my brain with joy, though its going to take me quite some time to get there I expect, as Ive got to learn both unity and max.

  • Max for Live always felt like a bit of opportunism to me. Is this really the best solution for users, or did Ableton and Cycling 74 just spot a collaboration too enticing to miss?

    Personally, I think that if Ableton had made an extension language from the ground up, it wouldn't have looked anything like Max, and it would have been far better integrated into the Ableton UX. This just feels like a hack.

  • browneye

    What it really means is that Pluggo is gone and replaced by M4L. That sucks if you were a developer wanting to sell patches. On the other hand it's great news for Live users. I don't develop and use Live so I'm pretty happy and it's a lower cost entry into the world of Max compared with standalone.

  • It seems like Ableton wants developers (hard and soft) for free.

    Again for me, better Flyloops or Logic 9.

  • Jaime Munarriz

    Many people were waiting for M4L just to have a Jitter window controlled from Live.

    You can do it, you just need to buy all the soft…

    Well, you can trigger video on Pd (I am doing it), or pay for a complete dedicated vj app like Modul8, Resolume, Arkaos

    or VVVV, TouchDesigner…

    I think this way you get a more powerful platform, for less money.

  • RichardL


    You cite ChucK on iPhone ("ChiP") as an example of open source alternatives on mobile, but I think on closer examination that you will discover that its really just another proprietary tool at this point. The source and even the binary libraries for the iPhone version of ChucK isn't open source. The expertise and development is all behind the proprietary version which is owned by a multimillion dollar venture-backed company. And that's fine, it's Ge Wang work. He has a right to take his graduate work and expertise and make proprietary products from them. But let's not pretend that it's some altruistic open source initiative at this point.

    Ge explains the state of affairs for ChiP in this post:

  • Ralf

    Just wanted to note that the issue 3 "Jitter output is crippled in Max for Live if you don’t also own Jitter." might be a bit misleading.

    When using an MfL device with a jitter Window

    in Live the output is as good as

    technically possible.

    On the other hand, the preview during editing

    is technically difficult in any respect,

    you also have more audio latency for example.

    Of course you can't make stand-alone Jitter

    apps without the Max license, but that

    wouldn't be fair to users who have paid much

    more for Max than MfL costs, would it?

  • Ralf

    @Jamie Bullock: I can ensure you that there is no way how Ableton could have developed something like Max with its many years of experience and great improvements over the last couple of years in the given time frame, if at all.

    And for the integration, please let me know where you think it looks like a hack, I'll have a look if we could improve it.

  • jngpng


    Agreed. It's also worth noting that the implementation of rjdj is also proprietary, hence there is no real open version of PD on the iPhone either.

  • continuous

    Really want to hear… or even better see… more about the Jitter side of things in M4L. Hopefully some good stuff will be out soon (or the M4L demo).

  • erf

    I don't blame Cycling74 for going with this model… I'm sure dealing the plethora of issues regarding plugins working on different systems was a nightmare. Altruism is nice, but it doesn't pay the bills.

    Unfortunately, the problem with expecting people to pony up for the M4L license to play with the new toys people will be making is that the creators have no financial incentive to do so. I'm sure M4L users will come up with some cool things with M4L, but I don't see a widespread release of these tools into the "wild", so to speak. Why should they? They'll get some Internet cred, perhaps, but it will be Cycling74 and Ableton that will profit from it.

    If you doubt this, look at the polish and utility of music applications on the iPhone between free and paid apps. People who pay $100 for a developer license generally want to see a reward for their effort. Combine the costs of Live + M4L and this effect will only be amplified.

    I'm sure some cool little widgets will proliferate, but I doubt many robust devices will be made… which sort of undermines the desire of people to pay $300 for M4L, unless they are including one hell of a step sequencer.

    That said, I'll buy M4L eventually since I own Max, but I doubt I will create many devices beyond the ones that suit my own needs.

  • apalomba

    Part of me feels shafted my Cycling because I

    was doing just find with Pluggo and Sonar, now

    I have to buy an entire new DAW. Granted Live

    has plenty of good things in it that make it

    worth it so I guess I can't complain too much,

    but still…

    I think the end result is a good one: Max users got a timeline that is pretty kick ass, and Live users have the ability to create and customize to their hearts content. So if I am

    going to invest future money into an audio

    development environment, I think Ableton/Cycling is pretty much the cutting edge.

  • surprised about the jitter crippling, seems such an annoying inconvenience. I'd expect such things from dodgy internet crippleware but it's a bit disappointing seeing it come from cycling74. I've bought my copy of m4l and luckily i already own max otherwise i'd be kicking up a shit as jitter was the main draw card for me – like many others i'm sure.

    have gotten a little midi video player going…
    …but would have been a major pain getting it running minus the jitwindow in edit mode.

    with the right patch max4live could really rival a lot of vj programs out there, especially with it's way wicked midi mapping.

  • Regarding RjDj and Smule's ports of Pd and ChucK, respectively:

    Pd and ChucK remain open source, whether these implementations are or not. The assumption that these folks have done something magical to make these tools work on the iPhone (or on other mobile devices) is not correct. You can compile them yourself. In fact, I've personally been working with Hans-Christoph Steiner and others on making Pd run on the BUG Labs device and Android.

    Anyone is free to take this stuff and run it anywhere – that's the point. In the case of Pd, Hans-Christoph has put it on old, discarded iPods and PocketPCs. For the price of one iPhone fart app, you could have an entire, programmable platform.

    Now, I certainly don't think everyone should have to reinvent this work. Our friend Memo has done a wonderful job sharing how to work with openFrameworks on the iPhone:

    That's actually the example I probably should have used. That's (potentially) a fully open-source toolchain, exquisitely well documented, and it's led to a number of creative audiovisual apps on the iPhone. You rely on a proprietary platform underneath, of course, but this could also be applied to other platforms. (Symbian, Android, and Linux mobiles are all open-source. Android has gotten some flak for not having a fully open phone stack, but that's not what we're using here.)

    As for RjDj and Smule, I believe both developers have expressed a desire to continue to support open source development. Ge Wang said as much during his interview for CDM.

    I don't have anything public to share right now, but I expect to continue to cover this. I'm certainly not going to hold anything back I'm working on – not when I know some really brilliant people tackling this on the open side. I'd like these efforts to be further along than they are.

    Again, I don't wish to take away from the utility of Max in Live in Max for Live. But if you want to do something "for" other things, these solutions are, by definition, not terribly portable. That's not a statement of opinion; it's a matter of fact.

  • @Ralf, sure, I can see that it was a commercial no brainer to combine Max and Live. It makes very good business sense. However, the problem you have solved is 'how can we make Max available inside Live so users can make extensions/effects with it?'. I think you have solved this very well, and it will make a lot of people happy. It is a great product, and from this perspective there is no hack.

    However, the more interesting question would have been: 'how can we make the best possible system for users to create their own extensions/effects/instruments inside live?'. I'm convinced that if Ableton had approached this problem 'carte blanche' with no a priori knowledge of Max, the result would have been more seamless, usable, exciting and revolutionary than M4L.

    The hackiness of this is in the concept — in the way you have stitched together two distinct products, and whilst you have inherited Max's great strengths, you have also inherited its weaknesses.

  • sxa

    Your correction about Pluggo being sold separately from Max is still slightly incorrect. From Max4.5 onwards, it was possible to build and export a Pluggo from Max whether you owned the Pluggo bundle or not. The Pluggo bundle was, from that point, basically just a set of Pluggo-built plugins. Of course, that wasnt made fully obvious when Max4.5 came out, and some people Pluggo with it, thinking it was still needed.

    However the documentation on building Pluggos, and the Pluggo-specific Max objects, was only included with the Pluggo bundle, so you still needed to get hold of a version of Pluggo if you wanted the documentation; luckily it was included in the demo.

  • JohnG

    Speaking of iPhone music software, SuperCollider now comes with an iPhone XCode project file. Fully open source. There are a couple of videos up of people running SC on their iPhones.

  • @sxa: Thanks; adjusted.

    @JohnG: Yep, absolutely… and we should try to make SuperCollider work on Android, too. 😉

    I should also credit this project on the Pd side:

    It's unique from even these other efforts in ChucK and SuperCollider in that it was specifically optimized for very low-end hardware.

  • The thing is that a similar solution to the problem "how can I run extra effects and instruments not shipped with live" already existed and it's called vst plugins.

    Now of course max for live allows these tools to interact much deeper than the vst spec does. But nothing prevented ableton from release an api for plugins that exposes as much of live to those plugins as it does to max.

    It would have allowed for a much more open and portable product (and if done correctly even binary plugins that didn't reveal their source to anyone using them).

  • @Kyran: well, that would be the Live API. As far as I know, it is as exposed via Python as before, and thanks to Max for Live, it's better documented. It's unlikely to be available to VST/AU plug-ins, but it should be accessible via OSC and MIDI.

  • JohnG

    @ Peter

    Can you do everything with the Live Python API that you can do in M4L (besides visuals)?

  • @JohnG: I believe you can do everything with the Python API that you can do with the Live API itself in Max. Of course, you can't build devices, and you still don't have Max/MSP/Jitter and everything it does!

  • Ralf

    @Jamie Bullock: I see what you mean. IIRC, there were actually some thoughts, many years ago, about providing a way for the users to make thier own DSP in Live and to build their own GUIs. I was not directly involved in the discussions, but I remember that after understanding what that means there were concerns to redraw too many resources from the main product.

  • @Peter: Agreed, Memo et al's work on ofxiphone is a very good example. The others are just well intentioned declarations of future goodness. Exigencies tend to take a toll on those. And as we've seen with Pluggo for Max 5 declarations of future goodness can sometimes lead to disappointment.

    > The assumption that these folks have done something magical to make these tools work on the iPhone (or on other mobile devices) is not correct. You can compile them yourself.

    Maybe-maybe not. It's important to acknowledge that software development is much more than just access to a code repository. As I'm sure you are aware being in the thick of it now, there are many other factors besides access to a code branch that play into successfully moving an OSS initiative forward — the quality of the code (research project code is often not built with commercial-grade robustness – the difference can sometimes take years to work to make up on a complex project); the experience and design ideas of the architect and engineers who built the thing in the first place (code is not just a logbook where improvements and embellishments can just be tacked on by any willing and well-meaning engineer), variations in quality of code and design documentation.

    I am looking forward to more news of your work with Pd on the Android. It sounds like you are having some success.

  • @RichardL: Well, they're more than "intentioned declarations of future goodness"; I'm working with a couple of them! The SuperCollider project is out there and running and includes an Xcode sample project for added convenience, as noted here.

    I was speaking specifically to the case of ChucK, Pd, and SuperCollider; it's fairly easy to compile these on alternative platforms (particularly Pd).

    Leaving code in a code repository does not good free and open source software make, it's absolutely true (though it may not hurt, either).

    So, let's be clear about what we're talking about here, beyond compilation.

    For sound applications, you need:

    1. An audio driver with which the software can communicate

    2. Possibly some optimizations allowing for different hardware (PDanywhere has the advantage of being optimized for integer calculations, which is why it's useful on gadgets without an FPU – floating point emulation works, but it's slow)

    3. On devices that don't run native applications directly, some sort of bridge to the preferred language… as with Java on Android, using JNI

    4. The ability to run without the graphic interface, as Csound, ChucK, SuperCollider, Pd (unless we're talking something like Processing or OpenFrameworks, which can be adapted to do graphics on the hardware, obviously part of the appeal)

    Using open standards and open source components as your foundation makes all of these things easier, as well. Even in the case of Max/MSP, the use of JUCE should make ports to other platforms easier.

  • @Peter: All good points.

    To clarify, I was specifically referring to the good intentions of the two OSS projects you cited but that have gone proprietary: Rjdj and Smule. Not OSS efforts in general.

    Your list of requirements for OSS tools is a good start. A major additional point I would add — since we are talking about the pros and cons of musical instrument developer tools and the "strings" that are attached to them — is licensing considerations and their implications.

    Not all open source software and IP licenses are the same, and some are not suitable for certain applications especially if you are mixing and matching platforms, tools and distribution mechanisms or markets. Obviously, at the extreme end of the spectrum GPL adds huge encumbrances on any derivative product. But even something so seemingly benign as the CC Sampling+1.0 license has a "no jingles"

    clause that prohibits the use of derivative products for advertising and makes the use of IP so licensed unsuitable in creating a general purpose musical instrument.

    Even the CC "by" attribution requirement become impractical when it means any song a user creates with your musical instrument must be accompanied by a laundry list of credits and URLs for it to be compliant.

    One can argue that the license burdens are passed to the user/consumer with open source tools and IP, but I'd argue that as a toolmaker one has a responsibility to create tools with practical licenses for the derivative products and encourage the users of them to support compliance.

  • @RichardL: Of course, I was talking technical requirements if you sit down and make this work. But yes, absolutely, agreed; I'm using the term open source to describe a galaxy rather than specific planets, and this stuff does indeed matter.

    Any work that's based on something like Pd or SuperCollider will be bound by its license first. SC has the GPL; Pd is under its own BSD-style license.

    This is pretty far afield from Max 5 and Max for Live. But to look broadly at the practical issues involved, to me this really is about whether you are built atop a project that is broadly portable or is not.

    Portability won't be an issue for everyone, or on every project, but it's worth saying.

  • gbsr

    salamanderanagram is just spot on. for example one of the most requested features for live is a midi lfo and now the disussion goes "do it with m4l". its great because now ableton doesnt need to focus on it and can just sit and reel in the cash they dont deserve. people are considering how to hack live so that they can get proper automation curves, another feature that has been requested for nearly 2 years straight (also one of hte most requested ones). whats even worse: max for live is unstable, and it is very poorly integrated and it does indeed feels like a hack. not to mention the fact that live isnt even stable yet and people are having big troubles with it, everything from constant crashes to things such as the looper still not wokring, which was one of the biggest selling points of live 8 together with the sahre function (which btw still is in beta, although it suddenly stopped working and noone knows why, not even ableton themselfes O.o). we are paying ableton to beta test their products.

    im fed up with ableton as a company and i am on the look out for any other daw that i can use instead of live. too bad i highly depend on the session view then. oh and trust me, i am not the only live user who is fed up.

  • wheel

    some very strange reactions on here

    Live is a remarkable DAW – it still has major weaknesses ( no half way decent automation curves, or quarter way decent crossfades being amonst them) but it also has a lot of major strengths and unique features.

    If it isn't right for you, fine, use something else … for those of us who find, despite the weaknesses, that it IS what they want to use for some or all of their work … there is now a new and unique set of possibilities available, that we can choose to add, or not.

    Is the implementation perfect ? undoubtedly not, but even as it is, the possibilities it opens up are so vast, and to many of us so damn interesting that for people to be complaining that they could / should not have gone with C74 and have done it from scratch seems just crazy.

    why don't you go complain that digidesign haven't written an in-house PD for PT ?


  • Well, I think the reasonable complaint — say constructive criticism — is that there isn't an open way of addressing *any* DAW using hardware controllers via various hacks on MIDI and Mackie Control and whatnot. That's not to sit around and gripe about it, though – let's talk about what that'd look like. OSC is there, but I think it's worth reflecting what an ideal implementation would be. Max for Live is something else; it's not an answer to that question and I don't think it should be intended as one.

    I'm unclear with the complaints in comments what people's background is, or what they would want as an alternative. My original post isn't a complaint; it's a reminder that there are other paths.

    Nor is Ableton the only developer looking at this. FL Studio added SynthMaker. It's much narrower than Max for Live, but it's included with most bundles and may actually be a bit easier if all you want to do is build a synth or effect. It's much less interesting for some of these other things.

    Reaper has not one but two ways of coding into the host, one which is more of a scripting environment and the other a full SDK. It's a very different approach to Max for Live, and so again has its own set of advantages and disadvantages. But it is also included with the host, meaning a solution you devise works for all Reaper users.

    Open source development is still an option — including for Live users.

    But yes, I agree — complaining is not a worthwhile use of time. Talking about different options and working on the ones that are most productive for you certainly is.

  • salamanderanagram

    "I’m unclear with the complaints in comments what people’s background is, or what they would want as an alternative."

    my problem is simple: there should be a free runtime. i don't believe this is a minor quibble, i think it is a huge problem.

    "In fact, representatives of both Ableton and Cycling ‘74 have told me that they expect that many people will buy Max for Live at that price for the sole purpose of running other people’s patches."

    good luck charging for maxforlive patches when people have already paid almost $1000 just for the software to run them. which basically means that ableton/cycling are expecting people to pay for maxforlive, and then develop something for *free*, with absolutely no way to lock down your content.

    also, you have ableton and cycling both basically admitting that they are planning on using other people's work to make their product one worth buying. that should tell you something right there. i'm frustrated by this because i want nothing more than the ability to make max patches inside ableton, but i can't help but feel that the implementation has been crippled to maximize profit at the expense of making it something where developers could be rewarded for their work. in turn, i think it's unlikely to reach a critical mass of developers for this reason, but i hope i'm wrong.

    what i would like to see instead, and a way that i think would be more profitable to all parties involved would be the iphone model: have a free runtime, developers pay for the full version and sell patches thru a central store that prevents piracy and ableton/cycling make their money from developers and a small take off of any patch sold thru the central store.

  • wheel

    "you have ableton and cycling both basically admitting that they are planning on using other people’s work to make their product one worth buying"


    if you would like to be able to, ahem, "extend" Live yourself, and / or use other people's "extensions" … you get m4l, .. if not, don't … why should ableton "admit" this ? is it something to be ashamed of ? for me it seems to be just about the single most exciting & liberating thing to happen to electronic music making in quite a while … as for c74, their 'product' – max -has always been about what you, or others, can so with it , rather than what comes out of the box … thats the whole point of Max ! so they probably do"admit" to that heinous crime too 😉

    … and, just to throw the pigeon amongst the cats, i wouldn't be too sure about this "absolutely no way to lock down your content" thing, at least in the medium term … i don't know the details, but at the m4l "launch" at Ircam in Paris, Ircam announced the Ircamax plugs for m4l which are definitely going to be sold and are supposedly going to be protected & locked … they're not saying how (maybe they don't know ;-)) but thats what was said … so its very, very early days in the m4l ecosystem …

  • salamanderanagram


    perhaps you missed this quote?

    “In fact, representatives of both Ableton and Cycling ‘74 have told me that they expect that many people will buy Max for Live at that price for the sole purpose of running other people’s patches.”

    seeing as max/msp patches can be edited and copied just by hitting the unlock button i'm not sure how they'll achieve locking down content. then you have an ecosystem where you need to spend $500 or whatever for live + $300 for max for live + whatever the developer charges. it adds up pretty quick. and a free runtime would fix that problem IMO.

  • salamanderanagram

    not to mention the only reason i can see to upgrade to live 8 is to use max for live. so even though i already have ableton suite, it's another $500 for me just to run the programs that someone else has written.

    and yeah i'll bitch about it, but i'll probably end up buying it too. i'm just annoyed with the implementation and will be waiting to see it achieves critical mass or not.

  • wheel

    > salamander "perhaps you missed this quote?"

    no i didn't miss it, i just don't see that there is anything wrong with that. the same could be said for reaktor … so what ? if people want to buy it for that purpose, fine with me ! there's nothing shameful to "admit" !

    i bought Max/MSP and use it primarily to program my own patches and I also bought Reaktor and use it primarily to use other people's creations. I'm extremely happy with both and consider both excellent value for money compared to pretty much anything else out there.

    I have now bought m4l and will use it both for my own patches and other peoples … should i be ashamed ?? 😉

    i can certainly see why many people would be happy to see a cheap m4l runtime, and maybe it will happen sooner or later, till then what we've got is IMHO a fantastic and exciting step forward ….

    as for : "seeing as max/msp patches can be edited and copied just by hitting the unlock button i’m not sure how they’ll achieve locking down content "

    as I alreday said i'm not sure how either, but they are going to be sellling it (the IrcaMAX maxforlive patch bundle) (… for $99 if i remember correctly) and I specifically asked (at the Paris launch event) if it would be unlockable / editable and was told : NO ! … so …

    Actually I don't really see why it would be so hard to make it possible to lock m4l patches … maybe they will offer this possibility to "content creation partners" or something …. dunno … it's pure speculation at this point, but that is DEFINITELY what Ircam were saying ….

  • salamanderanagram

    "there’s nothing shameful to “admit” !"

    "should i be ashamed ?? ;-)"

    let's be clear. i never once used the word "shame" or "ashamed" or even said that there was anything wrong with this. i said i believe it to be a poor choice and creates too large of an entry barrier. without a free runtime you're required to own 2 seperate, rather expensive programs (live 8 and max for live) just to run a patch. i find that ridiculous.

    as for locking down patches, i guess we'll wait until we see. but upon reading cycling '74's forum there is no easy way to lock down a max patch. seeing as max is basically impossible to pirate i would like to see some of that same protection extended to the developers who wish to extend the platform; instead their forum basically says "deal with it."

  • A question from a MAX newbie (my real case)

    If you see a complete boxed version of Pluggo for less than 40 euros, would you get it?. As I understand, I could run the whole Pluggo legacy that's out there, and really cheap.

    Or is M4L going to kill the previous free runtime?

    I've got a Pentium 4 (no dual core, no 64 bits) running Ubuntu Studio / WinXP with a selection of interesting and lightweight plugins. I record my mac running Live in sync with hardware gear with that Ubuntu / Windows box. No latency problems. One computer makes the noise, the other records it. All using not-really-state-of-the-art equipment.

    So again, is Pluggo today a good cheap adition to my secondary DAW?

  • An old post, but one which takes on a special meaning in retrospect.