I saw some videos, where they did the obvious test with pro Q, set to linear mode, and oversampling, that ofc creates a lot of latency, but its not directly to cpu processing, the oversampling is just adding passes for more quality. It often comes down to the distortion reflection in digital systems - i dont know if that is a absolut valid test for the CPU.
Maybe also that flexibility leads to less producitvity, because at some point, if you dont commit - or progress, and keep tweaking endlessly, you dont get to the point of finishing stuff.
That bounce in place looks very slick, the browser, and the context browsing looked really good, and that is where i would like to see improvments in abelton too. The color full UI is nothing what i like tho - i am really happy with the minimalistic grey look of live. And i dont want to end up in a situation, where i have to maintain two DAW at the same time, that could also be a pita, if you pay for upgrades twice etc.
RNBO as it exists today may be somewhat orthogonal to M4L, but I wonder if the underlying technology ā the compiler toolchain ā could be leveraged by a future version of Live.
I wouldnāt be surprised if Ableton actually uses something related to RNBO internally when building new (native) Live devices. Speculation follows, but I think itās entirely possible that the likes of Meld and Roar began as prototypes in Max, and as the design became more finalized, the engineering team did some initial builds with their own (alpha-quality) Max-to-native compiler, and then proceeded to do more manual optimization and bugfixing to get them up to releasable standards.
If this speculation is accurate, Ableton could decide to invest in building out that internal tooling into something mature enough to be used by third parties. This could take several forms:
Compiler toolchain for developers (āRNBO4Lā)
Ableton-managed build and distribution infrastructure (Reason Studios Rack Extension model)
Install-time compile (I think Android does or did something like this for awhile?)
JIT compilation (like the JS engine in your web browser)
Each of these would have its own set of advantages and disadvantages, but this is probably enough LARPing as an Ableton product manager for one day. Still, I think thereās some real potential there for the next generation of Max for Live.
Not sure if it will have JIT, but Max 9 should come to Ableton integration soon, and it features, quote, āa new vision of code integration with patching - including a fully reinvented, fast and modern Javascript V8 engineā
Looking forward to that improvement! Might imply JIT.
"I assume there will be more portable, focused, products with a gentler learning curve , and others that give you a lot of deep and rich expression"
well at least we can stop hating on the idea of a push mini nowā¦ and looks like they will be investing in the move for the long run as well which is definitely comfortingā¦ Thanks Johannes
Whatever they do, I hope it leads to improved performance for M4L devices
Bitwig even has a feature of compiling its devices for the specific feature set your CPU has (e.g. floating-point and vector math libraries), so that they run optimally. I mean if team of 15 can do this, 500 easily can, too
Itās a bit of a chicken or the egg thing though, isnāt it. Would the modulators in Live even exist if it werenāt for Max for Live? The Live codebase is (from what Iāve heard) extremely complex, big and oldā so itās getting to a point where adding any new feature no matter how big or small becomes a very large task.
But regarding CPU usage, there has been a lot of effort put in by Cycling74 and Ableton to optimize the loading and processing of Max for Live devices which has had a big impact in real-world performance. So itās not like theyāre just twiddling their thumbs either.
JIT or not, something like Max is never going to be as performant as code built for a single purposeā thatās just how optimizations work. Optimizing for a single use case is fairly straightforward, but when the use case is largely unpredictable it gets a lot trickier.
Gen~ is JIT-compiled, but itās still an order of magnitude slower than, for example, writing some single-purpose code with low-level optimizations and/or SIMD instructions etc.
For what itās worth, most m4l developers I know that are serious about the format put a lot of effort into increasing performance. Regardless, I see m4l developers getting a lot of flack for not optimizing their stuff enough, but I think itās wholly unfair to expect native plugin performance of a Max for Live device. At the end of the day the format is what it is; and at some point you just have to follow through on the idea itself and settle with whatās good enoughā¢.
Technical stuff aside, I think Max for Live is interesting because it lowers the barrier of entry for making boutique effects/instruments/etc which means that youāll see ideas come to fruition from people who may not come from a software developer background; more likely they are musicians who are realizing something they would want to use themselves. I think thatās a very interesting perspective.
Iām of course biased (Max for Live is how Iāve been making my living for 4 years now), but just wanted to add my two cents to the discussion.
M4L devices are one of the main reasons I still use ableton tbh. I donāt notice much performance impact personally, tho my compositions tend to be not much more than 10 tracks ever.
I want to make it very clear that Iām not against Max/M4L existing, but - as I suggested in my post above - I see some problems with it. And probably āproblemsā isnāt the right word. āCompromisesā is probably better, because I agree weād not have lots of Live features, devices & burgeoning 3rd party dev ecosystem if it wasnāt for M4L. But the price that we pay for it is performance, potential instability and certain feel of clunkiness.
And I wouldnāt mind if it was completely optional - e.g. right now I donāt have any 3rd party M4L paid or free installed, despite buying lots of them, incl. yours - but as I said it provides Ableton with an excuse to never do certain things, because part of the community doesnāt care as long as thereās a clumsy, ugly, unstable and unsupported M4L device released 10 years ago, that kinda-sorta does that
Youāve not mentioned any particular devices I think?
I mentioned LFO & Granulator on purpose, because a) theyāre ānativeā / 1st party, b) their CPU toll is unreasonable compared to equivalent devices in other DAWs that do more & are way less taxing.
I was disputing your premise (that one can make M4L devices be light on CPU), not particular examples
I think some of it is Abletonās CPU meter is wonky. On my M2Max with an empty set, Ableton used 65% of a CPU and load was at 2.65%. I dropped, per your video, 1, 5, 10, 20, 40 LFOs on a track. Cutting and pasting a 20 at a time did take a couple seconds. Ableton then had my CPU meter at 34% with 40 LFOs on one track. (Latest 12.1 with newest standalone max 8 version). Activity monitor had load at 3.65% and Ableton at 74% of a CPU.
Something is strange there.
I understand there is some connection between the CPU meter and the number of samples used by the interface as it is partly reflecting buffer prep time for the audio interface. For the record I am at 128 samples 3.65ms delay on a Motu M4.
Specifically, it will tell you the occupancy of the most busy core (+/- some adjustment for disk
& RAM usage) so for example if you have a very heavy & long chain of devices on one track you can max the DSP out, but then adding new stuff on new track(s) (provided youāve a multicore CPU ) wonāt increase the load displayed there, because OS spreads the jobs across available cores, but in most cases it canāt spread the processing from single track (well, Bitwig can).
On M2 Max youāve a 12 core CPU, so when you had all of these LFOs on 1 track and saw 34% DSP, it makes sense that CPU utilization was much lower, i.e. 34% / 12 cores (8 p-cores, 4 e-cores, so itās not straightforward division by 12).
But my point is that 40 LFOs should never cause such a load - they just generate a number, based on some simple math function. If that was normal, weād have to worry about number of automation lanes we use. And we donāt.
The really interesting development with MAX for me is the direct integration with the piano rollā¦this takers almost no CPU and feels like integrated workflow. The possibilities are endless and to me it is far more useful then just modulating things. More and mores stuff coming out everyday- no other DAW will be able to keep up, as I said, its as close as you can get to open sourcing the DAWā¦
Still, I think thereās some real potential there for the next generation of Max for Live.
