Is Ableton Live suitable for any kind of real work?

[TomViolenz]

Sorry to hear about your misfortune. There is an easy and very imperfect solution to your problem. Don't use M4L. I know I don't, because I like a reliably and stable instrument in production and on stage.

Which is really odd since it is proprietary software. You would think M4L would work like a charm.

Depends on what you mean by proprietary. Is it owned and developed by someone? Yes of course!

Is it owned and developed by Ableton?! No it isn't!
They are just spending a god awful amount of resources and time on trying to shoehorn it into Live on a very fundamental level. (With not so great results IMO.)

So if you you meant native to Live software. Then no, not even close.

That's why all these stability, not recalling settings, taking over a parameters completely ( i.e. LFO etc.), added latency, high CPU use and other issues exist.

It's a creative IDE if you will, plugged in directly into a DAW. It's something for tinkerers, people with crazy cool new ideas that they can't program their own plug-ins for. 3rd party M4L plugs should always be bought with that in mind, because it come at the price mentioned above.

Ableton itself should NOT use it to develop the new devices it releases in Suite AT ALL (Convo Reverb, LFO etc.). They should work on making the smoothest, lightest, most stable devices they possibly can. And that will NEVER, no matter how good they may one day get the integration, be a M4L device. Because even then you are running an additional translation layer. There is a reason why most of us run our OSes native and not as emulations

[re:dream]

Completely agree with Tom.

@wavemonk - Please do refer the issue to Ableton. The difficulties with M4L are unacceptable, but they have been getting slowly better. And sending them support requests - NOT crash reports, but support requests - does result in change. Which will be of benefit to us all.

[Machinesworking]

Ableton itself should NOT use it to develop the new devices it releases in Suite AT ALL (Convo Reverb, LFO etc.). They should work on making the smoothest, lightest, most stable devices they possibly can. And that will NEVER, no matter how good they may one day get the integration, be a M4L device. Because even then you are running an additional translation layer. There is a reason why most of us run our OSes native and not as emulations

I agree with most of what you say, and was an early agitator against M4L on the forums. One thing though, plug ins are not running on an additional translation layer, not in the way you're insinuating. Integration between Cycling 74 code and Ableton code is an issue, but it's closest to running VSTs, which can and do run as stable as embedded plug ins.

To nerd out a little on this:
Cycling 74 have their own code bass and internal bug fixing in Max to begin with, then they have to write for integrating into Live fix issues they have there, then Ableton have to bug fix whatever is wrong in Live that messes up Max code. That's the big issue for stability.

Max is basically an object oriented language, it's got a big CPU cost based on it's modular approach, much more so than just straight code without object oriented access to it's inner workings. This is different than emulations, but it does cost CPU in much the same way if that's what you were getting at.

[TomViolenz]

Yeah compared to vsts, it could potentially be a wash, though I assume the comparison of a vst running in a vst (like Reaktor patches) would be more apt, no?!

But I always assumed that Lives own devices are closer to the general code of Live than even vsts are and that's why Operator and Sampler for example are so light and stable in respect to what they do. Am I wrong in this?
(This sort of system programming is obviously not my forte, so that's more than possible)

The only thing I can talk about is what my experiences with M4L are and it feels more like running Windows programs on Macs through Wine rather than Parallels, and certainly not like running it through Bootcamp, if you catch my comparison.

[musikmachine]

Completely agree with Tom.

@wavemonk - Please do refer the issue to Ableton. The difficulties with M4L are unacceptable, but they have been getting slowly better. And sending them support requests - NOT crash reports, but support requests - does result in change. Which will be of benefit to us all.

I was pretty disillusioned but i did this a few days ago along with crash reports, i want to use M4L and it does seem to be more stable in the latest beta as i've been able to load a bunch of max devices and reload the projects each time.

I'm sill not sure i'd start dropping devices all over projects but at least convo reverb works properly now so does appear to be improving.

Kazoo Core ftw!

[jbw]

I'm currently working on a M4L device, where you input animated gifs, and it outputs solid gold records.

Won't crash Live either.

[empathy1]

I'm currently working on a M4L device, where you input animated gifs, and it outputs solid gold records.

Won't crash Live either.

will pay for this one

[pencilrocket]

more flexible = more unstable. more limitation = more stable. There are no magic.

[Steve Glen]

I used ableton live to build a fence to keep hogs in, last summer. So yes.

[Machinesworking]

Yeah compared to vsts, it could potentially be a wash, though I assume the comparison of a vst running in a vst (like Reaktor patches) would be more apt, no?!

Reaktor is also an object oriented programming environment, I suppose not in the strictest sense of the term, but both Max/MSP and Reaktor allow a user to use objects to connect together larger programs, and you can if you wish use code to modify things. This can cause problems as it's much harder to test all variations considering the limitless amount this creates.

But I always assumed that Lives own devices are closer to the general code of Live than even vsts are and that's why Operator and Sampler for example are so light and stable in respect to what they do. Am I wrong in this?
(This sort of system programming is obviously not my forte, so that's more than possible)

One of my biggest complaints against Operator early on was that FM8 was less of a CPU pig than Operator! At this point I can't say that for sure? it's possible the code is cleaner? but there you go. They are however less likely to be affected by OS updates and drastic changes in Live upgrades for sure! Tension etc. are made by AAS, but the main issues with plug ins at least in my experience on OSX are GUI oriented, which are mostly VST/AU issues, when integrated without it's own GUI AAS plug ins for instance were all 64 bit right away instead of finally all 64 bit like AAS finished up as of last month. To AAS credit, all the new 64 plug ins that Suite ones were based on are now upgraded and far surpass Suite, so Live 11 will have that as an advantage maybe.

The only thing I can talk about is what my experiences with M4L are and it feels more like running Windows programs on Macs through Wine rather than Parallels, and certainly not like running it through Bootcamp, if you catch my comparison.

Mostly the problem is that object oriented style programming runs each 'object' with a ton of code out side of what it does, for instance a delay object in Max uses graphics and it's own self contained code that 'sides up' to other code, this is really dense and fat code wise compared to writing a native embedded plug in like Sampler. The conversation about Massive from NI at the time is relative to this, you could make Massive in Reaktor by patching it together, but it would be three times or more heavy on the CPU.

[TomViolenz]

^Thanks for the explanation.

I always thought Lives devices are even closer to the programs code making them so much lighter.
My most extreme example of this is the SimpleDelay. At times I had close to 300 of them in my set, hardly pegged my CPU at all. Any other delays I tried (vsts included) add significant CPU usage, even if I just try to load 20 of them.

[musikmachine]

I'm currently working on a M4L device, where you input animated gifs, and it outputs solid gold records.

Won't crash Live either.

Woohoo!

[ikeaboy]

I used ableton live to build a fence to keep hogs in, last summer. So yes.

I used ableton while painting the bathroom earlier this year and to be honest I was struggling to see the benefits.

[TomViolenz]

I used ableton live to build a fence to keep hogs in, last summer. So yes.

I used ableton while painting the bathroom earlier this year and to be honest I was struggling to see the benefits.

You were probably holding it wrong

[yur2die4]

I've made phone calls with Ableton Live by generating dial tones from Operator. No joke.

I wanted to mess with the person picking up with a busy signal but the GUI froze on me and I had to hard-quit Live to get that godawful noise to stop.