Ableton Forum

M4L is unstable. There is an inherent incompatibility between the two programs. Get rid of it. Stop wasting time and improve the massive gaps that users have been requesting for years and years. Like Scene Follow Actions. Pay M4L developers a small fee for the best creations and integrate properly into Ableton. E.g. lfo, shaper, nice stuff made for Live 9 that no longer works.

Hahahahahaha.... That is all...

Cheers
D

wongpongding wrote: ↑

Thu Oct 22, 2020 11:18 am

M4L is unstable. There is an inherent incompatibility between the two programs. Get rid of it. Stop wasting time and improve the massive gaps that users have been requesting for years and years. Like Scene Follow Actions. Pay M4L developers a small fee for the best creations and integrate properly into Ableton. E.g. lfo, shaper, nice stuff made for Live 9 that no longer works.

Agreed. It's a solution made by non-performers for performance applications.

Max is used a lot on live performances, in certain fields like art installations and more avant-garde stuff it may be more used than Live.

It is surprisingly popular with guitarists, for looping and audio FX.

Max is made by performers, many of the C74 programmers also perform, release records, etc.

There is no "inherent incompatibility between the two programs", quite the opposite, Live was literally prototyped in Max, back in the end of the 90s, Live's creators used Max before Live even existed,.

That’s right. Max was created by a performer (Miller Puckette) for performers. It’s purpose was literally to make programming control structures and instruments more accessible for musicians.

Also, the likelihood that most people who use M4L view it simply as a repository of free Ableton Live devices is merely a byproduct of the thing itself. It’s a programming environment embedded in a DAW, which is still something that’s unmatched in any other DAW.

So if you’re just a M4L “user” rather than a M4L User (Max programmer), then you’re always at the mercy of whoever coded whichever device you happen to be playing with at the moment, and you’re probably going to just blame Ableton and M4L for whatever problem you’re encountering because the nuance of where the problem actually lies is lost on you.

I’ve always wondered why Ableton don’t make more of a “buyer beware” kind of disclaimer with regard to M4L, because there’s so much that they simply can’t control with such an open system.

I vote for Unstable. I programm my own M4L Devices for many years now and Live with M4L was never realy stable. I would never use Live with M4L in a live situation. Shure it could be my M4L devices or not. I would be usefull to know what causes the crashes or what device. This crashes happen on all versions of Max and Live and on different PC. Sending crash reportes to Ableton and contact to the support was never helpfull.

stringtapper wrote: ↑

Sat Oct 24, 2020 6:02 am

...

This is a really balanced, informative reply. I understand the context way more now - thanks

doubleUG wrote: ↑

Sat Oct 24, 2020 7:09 am

I vote for Unstable. I programm my own M4L Devices for many years now and Live with M4L was never realy stable. I would never use Live with M4L in a live situation. Shure it could be my M4L devices or not. I would be usefull to know what causes the crashes or what device. This crashes happen on all versions of Max and Live and on different PC. Sending crash reportes to Ableton and contact to the support was never helpfull.

Well, unfortunately you are still at the mercy of the M4L device coder’s abilities… even if the coder is you.

I was very surprised when they included M4L. I could see the benefits of course - it’s a feature rich toolkit which was loved by Robert Henke and Gerhard way back before they even started Ableton. The attractions are obvious. The pitfalls though. Were equally obvious.

Way back when Live 8.0 was first released the app had a bit of a hiatus due to a prevalence of crashes. Whether this was the fault of M4L or an accumulation of digital dust is irrelevant now. The outcome at the time was that Gerhard wrote a mea culpa where he stated he’d strive to stamp out bugs and instability ,
This is what Gerhard said back then. viewtopic.php?f=1&t=132761
An article.
https://www.synthtopia.com/content/2009 ... ve-8-bugs/

So users waited and many bugs were resolved. The weak links in the chain were welded and made solid.

The only problem was: Max could still bring the whole parent crashing down if it misplaced a buffer, or was caught in a race condition. For many years there was a situation with the authentication hand off which would get trapped in a circular handshake. Many users would notice a crash on start due to this, or extreme startup times.

Though a decade later many issues still remain. Any chain is only as strong as it’s weakest link. Ableton invited idiots like me to make function calls on an api with little protection . I have many devices I’ve written which when I try to save them will corrupt not only themselves, but the parent live.als requiring a recovery by editing the xml. Many many times have I done this. Too many times have I sent 18 angry emails at 3 am to crashes@ableton.
They have the dumps.

To claim M4L is stable is laughable. It’s a chemistry set in a kindergarten. It’s never going to be stable.
It was never going to be stable.

To claim M4L is stable is laughable. It’s a chemistry set in a kindergarten. It’s never going to be stable.

Interesting analogy.

Agreed that a kindergartner with a chemistry set will most likely not achieve stability.

However, a college graduate with a chemistry set can achieve great things with no stability issues what so ever.

Stability comes down to the initial developer. Period.

I love M4L very much and pretty much use it all the time, for custom devices only.
Nevertheless, it's a pain to use. And it has some bugs.

- edit mode can crash super easily.
- edit mode introduces a huge latency that can make the whole process horrible.
- udp send/receive fucks up udp ports in a very inconsistent way.
- some graphical elements can load with wrong settings (see Convolution Reverb bugs...)

To be honest, M4L is a massive cause of stress to me. I think I would dream like a baby if I could trust it to work properly.
On one hand, it allowed my best dreams to come true and to have Live behave exactly how I want on stage. On the other hand, I always expect things to break and it's super stressful.

Angstrom wrote: ↑

Sat Oct 24, 2020 9:01 pm

To claim M4L is stable is laughable. It’s a chemistry set in a kindergarten. It’s never going to be stable.
It was never going to be stable.

Yes and yes.

19oclock wrote: ↑

Sun Nov 01, 2020 8:16 pm

Angstrom wrote: ↑

Sat Oct 24, 2020 9:01 pm

To claim M4L is stable is laughable. It’s a chemistry set in a kindergarten. It’s never going to be stable.
It was never going to be stable.

Yes and yes.

I should be clear that I mean: With great power comes great responsibility
Asking electronic musicians to do bug checking requires them to be competent and vigilant. Every time the user fails to be competent and vigilant will result in as much instability as the system allows.

As I read this thread and stew in misery over the fact that I've been encountering the same problems with M4L over and over over the years and not ‘able to’ figure out any lasting solutions, I wonder if any of you here with more experience might be open to helping a brother out.

Lack of stability is killing me. Angstrom says ""Max could still bring the whole parent crashing down if it misplaced a buffer, or was caught in a race condition."" and "I have many devices I’ve written which when I try to save them will corrupt not only themselves, but the parent live.als requiring a recovery by editing the xml. Many many times have I done this. Too many times have I sent 18 angry emails at 3 am to crashes@ableton."

I wonder if something similar is happening in my own workflow. I'll be able to build my set, introduce M4L devices, and while in that session be able to run things properly, but once I save the set, and then attempt to re-load it in the future, Live gets stuck on hang, plus I've then noticed that when I go back into the last-functional set which had my devices mapped properly, most of (if not all of, I'd have to double check) my M4L mappings are undone. I use a very large amount of Device Randomizer instances, for ex, and so having to go back and redo everything is way too time consuming.

It's entirely counterproductive for me to spend all this time mapping and building a set, if some unknown actions on my part, or particular instantiations of whichever specific device are to then mysteriously ‘corrupt’ all that work and set me back. Not knowing the nuts and bolts technicality of why this might be, I’ve done what I can to describe the issue here, but perhaps it would be best if I could get some folk to take a closer look and I can even send over the set itself.

I'm not a M4L coder and there's no doubt in my mind that what I've got going on could use some cleaning up as the code shows errors when I bring it up in Max and I don't know anything beyond 'seems to be kinda working now and doing what I want, I guess I'll stop messing with it'. And then it stops working and I’m back to square one.

Perhaps more knowledgable minds than mine might be able to suggest solutions or alternatives? Maybe you’re looking for a little side-project to kill some time? I can give more details to those interested, but generally speaking I am working on a compositional standard / ‘inter-gene-reactive’ audio/visual template which I use along with Resolume to create interactive / generative / reactive music videos & A/V installations. I think I’ve got a few ideas which are unique in the field (at least, I haven’t seen anyone else doing *quite* what I am), but without a stable proof of concept build that I can use to demo the techniques / template, who cares?

If this territory has been trodden before and someone can save me more headachery, I’d love you forever. If I could think of any alternative way to engineer this set which didn’t rely on (what appear to be) inconsistent tools, I would, but I can’t imagine any other possibility without using Max.

HELP.

djorno wrote: ↑

Fri Nov 06, 2020 1:45 am

I use a very large amount of Device Randomizer instances

You can achieve this with ClyphX Pro without the need for maxforlive.

Cheers
D