Managed to have a little play around today at last. There is a lot of new stuff to get to grips with and haven’t touched a lot of it but I have to say the browser improvements are worth the price alone for me - can see that being super powerful. Meld and Roar look like excellent additions but a lot to get to grips with. Haven’t even got going with some of the other bits like the midi improvements yet.
The improvements to the modulators are nice but couldn’t help but feel slightly disappointed when I tried to add a second modulator to a target and was told ‘no’ - I might be wrong but it seems like the changes there are mostly how it looks/feels rather than adding any additional functionality.
Migration to the new version has been really smooth here, and I haven’t noticed any performance issues but my projects rarely brushed up against any hardware limits on the prior version either, so that’s not to say there hasn’t been a change.
Checking in after loading a large project from Ableton 11 into 12…WOW!! This project was starting to choke my 2019 intel MBP in 11; and in Ableton 12, I have so much more power to keep my progress going. No need to freeze anything yet.
This project has A LOT of processing going on and I’m redlining some limiters hard, which I’ve found, in my experience, takes up a lot of resources…but in Ableton 12 I’ve suddenly gone from 80% -120% cpu to 40%-60%.
HUGE!!!
I’m loving the new additions in 12 as-well. 12 was wayy worth it.
I am hoping that what we have at launch is a v1 of the new modulation, and it’s laying the foundations for multiple modulators in future. I could be wrong, but my guess is they’ve overhauled the underlying code to be more flexible but maybe didn’t want to take on the UX challenge of how to represent multiple modulators at the same time.
Ditto…I think Bitwig got a lot of new users based on the excerpt unified modulation system…Ableton will have taken notice and the addition of a modulation folder in the browser is promising…at least we can manually modulate something with automation now!
Yeah, from a software development point of view I think some of the core stuff in ableton is pretty old (I remember a talk from their founder a few years back where he said some of the core audio engine code is still from v1!) but they’re taking the sensible (and to be honest, probably the only realistic) approach of gradually modernising it rather than rewriting the whole thing.
I’d be amazed if they had rebuilt the modulation system without considering being able to add multiple modulators, but it is definitely a lot more challenging from a user experience point of view (how do you show there are multiple things modulating and how each contributes? How do you edit them?) so I’d imagine that rather than getting bogged down in a potentially lengthy project to do it all at once, they’re taking a gradual approach and first replacing what’s there with the new underlying system, then in future hopefully expanding upon it.
Is there anything to suggest they have actually rebuilt the modulation system though? All I a see that has changed is very much a UX development that now modulators can be set as an editable absolute value + relative modulation, whereas before it was just the absolute boundaries that were modulated between.
I’d be happy to be wrong but it’s not clear to me this is anything other than a pretty surface level tweak with the underlying code left unchanged. There is nothing on their website that suggests it was ever any more than this to be fair and it’s a welcome addition regardless.
I am not sure how much rebuilding was required, but it is certainly touted as a new feature and gibes me hope modulation is being looked at.
### New Modulation Behavior
Modulation destinations are no longer taken over by the modulation source. This means you can still adjust the parameter being modulated, even after assigning an LFO or other modulation source to it, opening up faster workflows, more possibilities for performance and continuous real-time control of parameters.
I think it has changed under the hood, at least based on what you can access from Max for Live.
Previously there was no notion of a “modulation amount” - you could just take control of a parameter and set its absolute value (using live.remote). It was up to your device to introduce the idea of a “center” value and mod amount and calculate the resulting final parameter value by adding the two.
With the new system (live.modulate), you can just set the mod amount (offset) and the device itself handles the logic of adding that to the current value.
Also, in the old system, a Max for Live device taking control of a parameter caused it to be “locked”, whereas now you can interact with the original parameter.
Old Max for Live device controls can’t be taken over in the new “modulate” way, they need updating, so this also points to something fundamental changing under the hood.
So yeah I’m pretty sure they’ve introduced the concept of modulation being an offset from a value that a device owns, rather than modulator devices having to calculate the “final value” themselves… and if they’ve implemented this, then from a code perspective it’s probably pretty easy to add in more than one modulator - it’s just another value you add to the base value - so I’d be amazed if they didn’t build it with this in mind.
I think the trickier bit is how you represent this in the interface, which is probably why we are still limited to one modulator for now. There might also be performance or stability concerns I guess.
Thanks for this reply - really informative and it’s good to hear that my suspicions above aren’t correct. Will be interesting to see what comes next.
One thing that used to be an annoyance was when automating the offset value the range window was always a bit whacky, so even just having access to automate a parameter directly that is also being modulated is a big quality of life upgrade.
A while back, over at Centercode, a developer hinted at upcoming LFO performance improvements, mostly by deactivating unused mod destinations iirc. I’m not sure they’re going to overhaul the whole system, but I’d certainly appreciate it.
Until then, I’m using modulators by k-devices to combine several sources, works well enough. Still waiting on an update to support the new modulation system, though.
If you want to use multiple modulators on one target, you could do this by modulating the offset of the first modulator with the second and so on. So, lfo 1 targets filter cutoff. Lfo 2 targets offset of lfo 1. Effectively also modulating filter cutoff.
But less direct but more or less the same result possible.
At least, from the top of my head. Correct me if I’m wrong
From looking into this I’m pretty sure the answer to is no, but does anyone know is there a way of controlling the auto-warp function for long samples? I’ve been putting together a DJ set with a lot of disco and soul and while in a lot of ways the default warping is very impressive, in many cases it tends to quantise the life out of material by insisting on putting a warp marker on every bar.
It’s not a huge deal to go in and do it manually which is always my approach when I used to DJ regularly with Ableton, but it does seem like just having the auto-warp mechanism put in fewer markers is an acceptable compromise in terms of efficiency vs. results. One every four bars seems to be about the sweet spot for me on most tracks with live drummers, at least as a starting point. And I guess it’s easier to auto-warp and then go in and delete the unhelpful markers than do it manually from scratch.
But just wondering is there some way of telling Ableton to do it this way or maybe a possible max solution to delete every second marker in a clip?
Thanks - yeah, that’s what I figured. I must have a look at the options.txt and see is there something I can change to make it a marker every four bars … but on the other hand sometimes every bar is useful and I wouldn’t fancy having to go in to edit the file every time I want to change, so I guess just manually deleting the ones I feel are excessive is probably the best I’m gonna do.