Yeah, that bugs me. There a lot of really nice QOL Bitwig features that Ableton should really have implemented by now but they can rely on M4L to plug holes.
Not a chance 
I donāt really have the time to āmakeā music as it is already, so diluting it even further to tinker in M4L would be silly of me. Actually, thatās one of the reasons I ditched Bitwig and Grid is 10x easier & faster to work with than M4L (while only -20% less capable) 
the free max for live bundle from dillon bastan has the āMarkov Variationsā device in it which does exactly that⦠but you need max for live obviously.
no idea why th equote is in there⦠tried to edit it out but forum wonāt let me edit the post.
The feature Iām really after right now is one where Live will tell me which piece of shit track, or plug-in, is blocking opening projects. Hate sifting through, trying to pinpoint the bugger.
Underrated take, tbh. I love M4L, and itās incredible to have a DAW that offers such unparalleled extendability ā but these are all true.
I simultaneously love that I can buy an Elektron-like mini groovebox for Live that fits seamlessly into the UI, and hate that it feels like Iām running Crysis in Javascript every time I load it. I love that itās possible to find anything from obscure audio effects to obvious workflow enhancers, and hate that two thirds look like someone created them in Visual Basic 1.0.
M4L is a great idea, executed better than anyone else has⦠which as the only one of its kind, is unfortunately not a high bar. If Ableton and Cycling '74 could further optimize the implementation (JIT compiling?), provide better design rails and prefab UI components / layouts to help guide amateur UI designers, and just go ahead and āSherlockā the most popular workflow enhancements every now and then, M4L could be so much more than it already is.
Rather M4L than holes, its almost like having the advantages of open source within a stable and powerful DAW.
To be honest, on my i9 PC MAX runs great (and I donāt have crashes either to be honest, but I pick and choose). MAX has improved 10 fold in the last few years both in terms of features and reliability, the devices we see now (an the level of integration with the DAW) are next levelā¦nothing else comes closeā¦with MAX developers like FORS and Dillon Bastan we will never be bored!
That would be really cool. My dream of an ultimate integration would be a Live version completely native in MAX. Not Max for Live but rather MAX Live. Thatās what I was hoping for when Ableton bought Cyclingā74.
Although the integration today is a night and day difference compared to Live 8, Iām always a bit critical of the additional layer, even if itās almost unnoticeable.
Really interesting points, Iād never thought of it like that. But I think M4L is such a net positive overall, no other DAW has an extensibility story like it. Once you start learning to build your own stuff in it, itās like taking the red pill lol.
But I do think your point about it absolving Ableton of responsibly for implementing things is a good one, and Iād love to see M4L get (even more) polished and integrated.
The thing about M4L for me is remembering the 600 utility devices I have. Much better to have a feature built into the DAW itself and within easy reach. Gripes aside, iām still grateful for it.
Your right ā¦
but I deeply enjoy Abletons DSP objects in Max9 ā¦
Itās such a great step forward ā¦
Yep, some good points on Max here overall. When I started using Live I thought it was a bit weird to have all these random plugins that arenāt plugins, some with very odd interfaces (almost as if it somehow theyāre a little chunk off a Myspace page from 1999 or something random) and seemingly little to no quality control.
That said, you can sortof tell when someone has thrown something from their development test bench onto the maxforlive website and left it, just by the date and the number of updates . Since these are usually one person, Iām not expecting extensive support and all that. But itās kinda ārun at your own risk.ā And honestly the only time Iāve had to reach out to support for something was (in the end) because a max device kept crashing my session. So there is an element of risk there.
Where it does get impressive is when someone does show that level of commitment. Usually you can tell They care because theyāve gone some way to dial in a GUI that sits within Abletonās style either partially or entirely. Notable makers Iāve used in this vein are Fors, ELPHNT, Dillon Bastan, MonoMono and encoder audio. They all make devices that could arguably be stock in Ableton. In the case of Fors, theyāve shown Ableton how to make a simple GUI in a tight space and some Live devices would benefit from a similar approach.
I think for a sensible fee, itās worth throwing a bit of support behind these folks to have them make and support the devices for the long term. That said it gives me slightly more confidence when something is delivered through the Ableton website honestly. It shouldnāt be a risk to buy things, and in that way 3rd party plugins could be seen as more reliable.
So yeah itās a 50/50 thing for me like a lot of you are saying here.
I personally love how if I want to do something different, I have the option of looking for a max device.
I also think that Ableton test the water via these devices to really see what people want.
I also read somewhere that Ableton like how quick it is to develop in Max, compared to how long it is to develop natively.
Sure, but imagine how much less of a CPU hogs would Granulator or ā¦LFO be if they were natively compiled devices? Even on my MBP M2 Pro dragging an LFO into the session is noticeable on the CPU meter, whereas I can instantiate 20 LFOs in Bitwig (which are audio rate, sample accurate and polyphonic!) or 20 Pulsars in Reason and itās like theyāre not there, because thatās the way it should be - they just generate numbers from some function. Same with Reasonās Grain, which has like 5x the features of Granulatorā¦
(thatās the video I made a year ago on my previous Surface Pro 8)
Surely by now there has to be a semi-automated way to compile the M4L ā Native, no?
Its called RNBO- it compiles MAX to VST! RNBO | Cycling '74
I dont have bitwig, but i notice that LFO behaviour insert behaviour quiete often - in my middle of the project stage i often come down to 70 to 90 tracks, and then have to render /clean the project, to continue working on. I use about 3-5 LFO per track, sometimes just to save time, and do less automation lanes.
If you run similar projects between bitwig and Live - is there a differnt track count upper limit ? I am asking because i thought i could possibly solve it with a HW upgrade to M4, but well if Bitwig gives me 30% performance - then i can keep the M2.
Thatās not how it works
Iām aware of RNBO but - as you say - it produces a VST, not Live native device, which means most of the integration with Live is gone.
BTW - this brings up something I was curious about: Live Standard has modulators, but doesnāt have M4L. So are the modulators in Standard compiled? If so, is there a performance benefit?
Tough call. Bitwig in general handles VSTs better (better performance, more stability due to sandboxing) and I was never considering CPU performance of modulators, because itās not a factor. But it has its shortcomings, too - no Capture or MIDI comping, poor piano roll (but way, WAY better audio editing), Grid is fast & easy, but can get quite CPU intensive quick because of the default 4x oversampling. Many people say - and I tend to agree - that Bitwig is for people who like to tinker with stuff, dig down into details; whereas Liveās instruments or FX are ātunedā around the sweet spots, so while less versatile and flexible, youāll get to where you want to be quicker most of the time.
Also, despite similarities to Live, I find it quite different, in some ways like a hybrid between Cubase and Live (from the workflow perspective).
Best to take a 30 day trial and see how it works for you.
Ahh, ok! Thanks 