Live itself is missing a **TON** of features that M4L helps fill in for like LFO knob controllers, patterned knob controllers, better arpeggiators, great instruments, etc, but i find that more often than not right now, it's actually unusable because these tools stop working over time!
Here's some examples.

1 : MONO SEQUENCER : i load that up and it works fine for about a minute or so and then becomes graphically unresponsive. where it only redraws the gui if you click on the screen which makes it basically unusable.

2 : i'm a scripter myself and i created a tool to send/receive data between tracks (and they use unique IDs to know whom to talk to). i found that after i had about two or three of these instances loaded, i couldn't load anymore because they'd be magically breaking each other's send/receive communications.

3 : i have another script that's insanely basic. all it does is let me push a hotkey and it will push the record button on the first empty clip of the armed track. very basic and i use it all the time. but the problem is that after i've been working in a song for many days (with countless saves, ableton loads/closes, machine sleeps/wakes/reboots, etc), the hotkey will stop working (in that specific song). I looked into what's breaking it and for some magical reason, the ONE button my gui has is not even hotkey-bindable anymore! if you go into the hotkey binding mode, the button will not be colored to show that it's bindable. And what breaks this? Just having a song that i've been working on for weeks. nothing else. Deleting it and reloading it will not fix it. And i have nothing else regarding M4L in the scene, so no other M4L devices are magically breaking it like i was finding with my send/receive scripts. I seem to remember trying a couple of tests with this specific breakage case and found that my button did still work. it's just that it wasn't hotkeyable. and if i pressed the EDIT M4L SCRIPT button, M4L would crash when opening the script. So a very basic script is completely tearing M4L apart from the inside, only because the song is now very long and complex and has a TON of devices, clips, scenes, etc etc etc.... That's the level of insanity I'm dealing with.

4 : i had another script i was using (can't remember which one) that would work fine on small songs, but on a large song that's been in production for a week, it would eventually break to the point that if you load the song and press play, the script will work for that first playthrough and never again on any other times you hit the play button. and my song was 100% dependent on that script, so it was a real hassle to work on that song. That problem didn't start until i was at about the 75% level of completion on that song, so it worked for many many days and then could no longer work properly for an unknown reason. nothing changed except the song was older and had more content.

So basically, i've had to just stop using M4L because i can't trust it to work. I tried deleting my preferences (and default scene) to see if that would help at all, but nope.

I'm a *HEAVY* scripter for other programs and there's COUNTLESS features ableton is blatantly missing that i'd love to just create by myself, but i've found that M4L's got two lethal problems. 1)it's only exposed to less than half of the ableton application in the API when it needs to be ALL. 2)in my experience, it breaks nonstop and it's not the scripter's fault. So in the end that means it's unusable in actual production. I've also been using M4L for years and it's had this same level of breakage, so it's not a new problem.

So I guess what i'm curious about is am I the only person that's magically running into these problems? Or is everyone, and that M4L really only works when you have brand new basic songs and thus isn't usable in full production?!

indigosm wrote:
So I guess what i'm curious about is am I the only person that's magically running into these problems? Or is everyone, and that M4L really only works when you have brand new basic songs and thus isn't usable in full production?!

You may not be the only one, but that experience certainly isn't the norm. A lot of my personal (and sometimes professional) work has components I've made in M4L, and they don't magically break - I've used m4l devices consistently on stage for years. I've made devices for people that have used them in rehearsals and performances. When things break, there's almost always a reason.

So I loaded up one of the songs that was breaking M4L and it took a LOT of testing but i finally found what was breaking M4L. For some magical reason, having a certain VST in the song (BYOME) was breaking ALL M4L devices in the song. The only way to fix that is to delete all BYOMEs, then save the song and close/restart ableton.

So I'm sadly not making this stuff up..

I'll be bugreporting this and all the other reproducible M4L corruptions I find as this really needs to be resolved..

dataf1ow wrote:I didn't say you were making it up, I just suggested that there was a reason these things were happening, and that it wasn't magical. Seems you found the reason.

oh no problem. i've actually been seeing M4L get corrupted long before byome ever came out so it itself can't be at fault. it's something else and i wanna try and bug report 3 different cases of it getting corrupted. if all 3 are different bugs, i'd be really curious to see why i'm seeing this corruption more often than others might be seeing it...

I totally agree that it's a very very clumsy and unreliable method of customizing Live. It's such a memory hog on account of it's pipes-and-devices layout and totally unsuited for professional usage, in my opinion. All of the commercial software pieces created in M4L that I've used have been horrendous and prone to eating shit before you can even get a few minutes into performing. Maybe use M4L for some prototyping, but beyond that implementation should be done in a proper programming language.

The big thing that it offers are some inroads to the Live API. Happily you can use Java and JavaScript to build out devices and get away from the banging-rocks-together approach that M4L is by default. Anything more than a couple of objects in a device and I step back to see what I've done wrong.

You're not alone. I'm running my setup on a six (or seven?) year old ThinkPad and it hums, but only after totally ditching M4L's stock re-imaginings of the wheel.

indigosm wrote:i'm running win8 on a macbook pro from 2014 or so. i'd be surprised if it's OS related but who knows.

I wouldn't.

Max was Mac-centric software pretty much from its inception (early prototypes on NeXT in the late 80's; first Windows version in 2003).

I have noticed a trend on these forums over the years since M4L was released that Windows users always seem to have more trouble with it than Mac users. A lot of it seemed to stem from authorization issues in the Live 8/9 days, but with the new Live 10/Max 8 paradigm those *seem* to have lessened.

19oclock wrote:Anything more than a couple of objects in a device and I step back to see what I've done wrong.

That's insane, and certainly not even in the same universe as my own experiences.

I'm curious as to whether the people in this thread who have these extreme issues are PC users.

Oh, I'm not saying that devices become problematic, just that Max is a kludgy shit show attempt at mimicking true programming. It's just so much more advisable to use Java/JavaScript/insert-external-libraries-here when doing anything more than some prototyping within M4L.

Once I have an idea figured out I'll move it to production and get rid of anything other than a maybe a metro object to work with the code.

19oclock wrote:Max is a kludgy shit show attempt at mimicking true programming

Sorry, I can’t let this comment pass unchallenged. Max is a Turing complete programming language that has been around for a very long time (and is based on languages that have been around even longer). The fact that it does not look like many of the ‘standard’ text-based languages does not mean that it is any less of a programming language as a result.

Yes, I too tend to use JavaScript within Max when it seems easier for a given task. I also often write my own ‘externals’ in C when this is more appropriate. (Indeed, these might be more accurately called ‘internals’ because they effectively become part of Max.) But this extensibility does not detract from Max itself. Quite the contrary: it makes the language that much more powerful.

Max is a very capable language (and development environment) for DSP and audio—when in the hands of a good programmer. As a programming language it is semantically nothing more nor less than a bog-standard object-oriented language. It just happens to have a visual-oriented syntax.