Later this year, Ableton Live will only be available in a 64-bit version. But what does that mean for you?

This is a development that has some implications for Ableton Live’s compatibility, stability, the pace of features and improvements, and that question of “wait, which version am I supposed to choose on the Ableton download page?” Ableton invited CDM to their offices across town here in Berlin, to discuss the change. That has given us a chance to understand the thinking behind the decision and to help figure out what users might want to know.

But first, it’s actually worth understanding what 64-bit music software actually does.

What are 64-bit and 32-bit, anyway?

First, you know, 64-bit is twice as much as 32-bit, which means it’s twice as … well, 32 more … double the …

Okay, let’s be honest, even lots of fairly tech-savvy don’t really know what these terms mean, let alone what impact they have in real-world use.

Software runs on numbers. So when we refer to “64-bit” or “32-bit” software, we’re talking about the word length, or precision, of the numbers the software uses to reference memory. If you have a higher word length, you have more precision, and the software can address more memory.

Think of phone numbers for comparison. Leave out the area code and country code, and you eventually run out of available phone numbers. But add some additional digits, and you have more available numbers – and you can call a greater number of individual people.

With 32-bit software, Ableton Live and all of its plug-ins can use only up to 4 GB of available RAM (or even less on some versions of Windows). But 64-bit software can address all of your RAM, on any computer sold today. (The theoretical limit is so high, you can’t even buy a computer that comes close to hitting the ceiling, at least for the foreseeable future.)

What does more memory mean when you’re making music?

If you have a computer with 8GB or 16GB or more of RAM, there’s some reason to want to use all of that memory. As you load big sample libraries, and add plug-ins or ReWire clients, and as your Live set grows, all of that uses up memory.

Oh, yeah, and one other thing – running out of RAM can cause a DAW to crash. You might not even know that was the cause of a crash: Live crashes, you curse, and you might not realize that the choice you made on that dropdown when you downloaded could be a factor.

32-bit and backwards compatibility

Live added 64-bit support way back at Live 8.4 – that’s the summer of 2012. So if 64-bit is better than 32-bit, why did Ableton keep making new 32-bit versions of its software for over five years?

Running a 64-bit DAW requires a 64-bit operating system – for Live, that’s a 64-bit version of Windows Vista or later, or Mac OS X 10.5 or later. (Microsoft has their own FAQ to help you figure out if you’ve got the right OS for 64-bit.)

64-bit DAWs also need 64-bit versions of plug-ins. Most plug-in developers have already updated their plug-ins for 64-bit, but some haven’t. (There are wrappers you can use, and these were more popular when DAWs first started to go 64-bit, but let’s not go there – especially since part of the idea here is to improve stability!)

Okay, so you need a 64-bit OS, you need to update your plug-ins, and you need to have more than 4GB of RAM for this to be useful. Back in 2012, a non-trivial population of Live users fit that description.

Years later, the picture looks different. Nearly everyone has more than 4GB of RAM, meaning they’re going to benefit from the 64-bit version of the software. And not everyone seems to be aware of that. Ableton tells us that 85% of current 32-bit Live users have more than 4GB of RAM. That means 85% of those 32-bit users are actually unable to take advantage of hardware they already own.

That tips the scales. Now Ableton Live’s user base may be better off without new 32-bit versions coming out than with them.

Why are these developers smiling? Going 64-bit only will make the development process faster – and the Live experience more crash-free. Also, Club Mate.

Why go 64-bit only?

First off, nothing is changing for versions of Live up through and including Live 9.7.4. You can still download and run those older versions in their 32-bit versions. And remember that you can install more than one version of Live on the same computer, side by side. So if you’ve got a Live set that uses some old 32-bit plug-in, you can keep a 32-bit version of Live on your machine to open it.

What’s changing is, that dropdown on the download page is going away for every version starting later this year. Ableton will only develop a 64-bit version of Live and Max for Live going forward.

The downside of this is pretty simple: you won’t be able to use some old 32-bit plug-in and the latest version of Live at the same time. (Though you can still use the older Live with the older plug-in.) You’ll also need a 64-bit operating system (though on the Mac side, Apple tends to drag you along to new OSes and new hardware, anyway).

But the upsides to forcing Live users to go 64-bit when they update may be bigger than you’d expect.

Fewer crashes. The 32-bit version of Live crashes more than the 64-bit version – a lot more. Ableton collect the number of crashes. The 32-bit version of Live crashes 44% more often than the 64-bit version.

Most of these crashes are as simple as Live running out of memory – not a bug, not a misbehaved plug-in, but just hitting that 3.5-4GB memory ceiling imposed by running a 32-bit version of the software. (Some may be the result of dubious old 32-bit plug-ins, too, but that’s also a reason to dump plug-ins that haven’t been updated to 64-bit.)

Fewer Live crashes overall means fewer people having to talk to support about these crashes, which is better for everybody.

Clarification: As some people in comments have pointed out, yes, if a DAW can allow a 32-bit plug-in access to 64-bit memory space, then you’d have a way around this problem. The short answer here is, the way Ableton Live’s plug-in architecture works – and, indeed, the vast majority of DAWs available today – requires a plug-in to be 64-bit native in order to use all available memory. Also, while “sandboxing” allows this, and prevents plug-ins from crashing the host, that has its own tradeoffs. (In comments, Paul Davis of Ardour and JACK fame says this approach doesn’t scale to large mixing sessions.

You’re still free to use “bridging” plug-ins for 32-bit support if you so choose; Ableton just haven’t officially supported that.

Faster updates. I also spoke with Ableton’s engineering side about why they’d want to drop 32-bit development.

Supporting both 32-bit and 64-bit versions of Live adds overhead to the entire development process. More overhead can translate to us getting fewer new features, or getting them less quickly.

That overhead impacts the time spent coding and debugging Ableton Live, not only for the humans, but also for the machines those humans rely on to do their work. When engineers make a change in Live’s code, they have to wait while servers build, test, and output the results. Even with a room full of racks of pricey, powerful computer hardware making that happen, the process takes hours, especially at peak times.

Take away the 32-bit side of things, and developers get their results faster. In practical terms, that could mean they get their change back today, instead of having to wait until coming into the office tomorrow morning. Since engineers typically like to stay focused and in the zone, that’s important.

Add everything together – supporting more use cases, more old plug-ins, dealing with more crashes, added development time to support two versions, added time to test and build two versions of the software – and you get a lot of added drag to Live’s development.

This isn’t just about making Ableton happy. Removing that drag from the process means those engineers can work on Live more efficiently. The upshot for us is, we get more the stuff we want – fixes and new features.

What you need to do

It may actually have taken more time to read this article than it will to make the leap to 64-bit Ableton Live use. But hopefully it gives you some notion of what’s going on in the world of the people making the software we use.

For your part, assuming you aren’t already running the 64-bit Ableton Live, here’s what to consider:

On Windows, you might want to double-check you have the 64-bit version of the OS installed. (Click your Start button, right-click Computer, click Properties. Under System, you’ll see which version of Windows you’re running.)

As far as checking your plug-ins, Ableton have some resources on the topic:

Recommendations for using VST plug-ins on Windows

Recommendations for using AU and VST plug-ins on Mac

Since 32-bit plug-ins don’t show up in the 64-bit version, the easiest way to check compatibility is to launch the 64-bit version and see if the plug-in disappears. (Don’t laugh – this really is the easiest method. I recognize it’s not optimal, but it seems at the moment there’s not an easier way to do this in most DAWs on Windows or Mac, either one.) If it’s invisible, odds are you need to go to the developer and download a 64-bit version, if available. And as mentioned earlier, you can still keep the 32-bit Live on your hard drive if you find a plug-in that requires it.

Ableton has published a new Knowledge Base article on the change:

Live 32-bit to be discontinued

Relevant to versions from 8.4 [64-bit introduction] through now [prior to going 64-bit only], here’s Ableton’s existing FAQ:

64-bit vs 32-bit – FAQ

I hope this gives you some insight into how Live works, and ideally makes your Live use more productive and crash-free. If you have any more questions, let us know.

Thanks to various engineers and product managers at Ableton who contributed to this story, particularly Alex Wiedemann (former Ableton software engineer and now head of Technical Support Berlin).

  • Pete Aurel Leuenberger

    Did theys say somethin’ about new features, skin, browser for the next major update?

  • Mario

    Ableton Live 10 is on the way! There’s no way they flew you out there just to talk about Live going 64-bit only. They showed you a preview. Your NDA probably keeps you from talking about it, so if you saw a preview of Live 10, just wiggle your left pinky.

    • Mario

      And if you saw Push 3, just blink rapidly.

    • Ian Scott

      Flew out… not so sure! I think Peter is a Berlin resident so I imagine he is regularly seen at the Ableton offices having gander at secret sauce.

      • Mario

        Aww hell

    • Yeah, I didn’t *walk* over there, but I did just take an U-Bahn 😀

      Anything in the future I leave you to guess about, but be assured CDM will be on top of all releases numbers greater than 9 (10, 11, 12, 13, not planning a retirement any time soon… )

  • Foosnark

    I’ve resisted switching to a 64-bit host for years. I still don’t really feel the need — I don’t use big sample libraries or load so many plugins that it would help.

    I have noticed that Maschine is a bit more efficient in 64-bit, but still didn’t switch because of my few 32-bit only plugins. Sorting through 150 plugins to figure out which I need to redownload and insall and which ones I’d be stuck without, was just not worth it.

    These days though, I’m so much into hardware that I could start with a fresh hard drive, install the dozen or so plugins that get any real use, and call it good.

    • Right – you’re exactly the edge case where updating doesn’t make sense. But remember that some people are in a similar case and then calling to complain when Live crashes because they don’t have enough available memory.

      You can always keep a 64-bit version handy, and run it to see what works. You don’t necessarily have to go through each plug-in individually.

      That said, it’s annoying that there isn’t a better way to maintain plug-ins, but … well, that’s one thing on a long list of things about plug-in architectures that’s annoying.

  • Klemen Kotar

    I’m expecting v10 to be announced at Loopfest 🙂

    k

    • Spankous

      when is this?

      • Linas Maknys

        November 10-12

        • Spankous

          Thank you!

          • Spankous

            Vst 3 support 4life. Live Life support vst 3. Meeeeeeeeeeeeeeeeeeeeep……

    • think so too!

  • Dave O Mahony

    Been using Live since buying v4 without any MAJOR issues. Tried 64bit at v8 and used it twice.
    Unless there is a stress-free, stable wrapper built-in to the software I cant see myself updating after the last 32bit version – its been a ride Ableton, a hell of a ride!
    I already have a ‘Frozen’ 10.7 system to keep using Kore (and all the cash I dumped into that) – I dont want another one and backwards compatibility is a HUGE issue for me.
    Side note – if 85% of users are still 32bit does that not tell them something?

    • Just to avoid confusion — I’ve reworded that from “Live users who use 32-bit Live” to “32-bit Live users.” That’s 85% of users *of 32-bit Live* who then aren’t able to use memory on their system.

      Ableton does indeed look at the number of people using the 32-bit release, and it’s gone way down.

      Ableton doesn’t have any plans for a 32-bit wrapper for plug-ins. Look, at this point – nearly all DAWs are 64-bit native. Computer systems are 64-bit. Most installed operating systems are 64-bit. The vast majority of machines have more than 4GB of RAM. If a developer isn’t making a 64-bit version of their plug-in available, that’s effectively shorthand for saying that plug-in isn’t supported, period. (It isn’t that hard to update plug-ins – in many cases, it’s as simple as ticking a box when you hit compile.)

      Hey, I know people making music on the Commodore 64 and the Game Boy. This doesn’t mean you have to give up a working machine. It just impacts the actively developed release – and because that’s the release that has fixes and new features a lot of users are asking for, that’s relevant.

      • Dave O Mahony

        Thanks Peter – that makes more sense to me. I do use a Gameboy/C64 too & Ive 16gig of ram. Im not butt-hurt or anything but what this means is that the system I have working now will have to stay as it is and I wont be upgrading. Shame but they gots to make progress I suppose. (I cant see the Smartelectronix or illformed plugins to mention 2 getting 64bit updates)

    • foljs

      Kore? Sticking with 32 bit in 2017? You seem to have a penchant for DOA technologies.

      • TJ Pallas

        32 bit architectures were the standard for decades, and continue to be in other applications – ithey’re not really “Dead On Arrival”…

        • PaulDavisTheFirst

          Any plugin API (or for that matter, any API at all) that has a dependency on the size of a pointer (memory address) is fundamentally broken. VST, in this sense, was “dead on arrival”.

      • Dave O Mahony

        Would you believe I have a mono Nagra open reel machine and a Tascam cassette 4-track?
        The 1k+ I put into Kore hardware and software, not to mention the time, galls so I decided to keep my sounds and use them in a ‘Frozen’ machine. (I know the answer is to “Let it go!” lol)
        Bought a Win10 tablet for my birthday in Sept just gone – guess what version Windows10 is on it!

        • Dubby Labby

          I see your point and my advice will be “use it as dedicated machine” like Reason-ina-box… then upgrade the available 64bits part of your study or buy more dedicated hardware. I’ve seen recently Roland VS2480 for 500€ in secondhand market…

          • Dave O Mahony

            I use a VS2000CD with my band mate (I dont drink often or do the drug thing but I do have a bit of a gear thing!) and it is invaluable, great bit of kit. We used it for many recordings and as backing track playback for live shows. Great kit!

            Looking at this more calmly – so long as 9 continues to work on my machine and the new one wont conflict, trying 10 shouldn’t be an issue and I am in the very lucky position that I have a loaner 10.9 laptop I can always try on.

            It just *seems* to ME, Ableton is saying ‘We are going this way, don’t care that you work another way, this is the way for you to go.’ Its actually not yet, for me.

          • Dubby Labby

            Ableton has this focus as NI, totally agreed. If you don’t need something about them or you can get an alternative go for it.
            I’m still missing a warping tool for iOS but for the rest (from drumracks to maxforlive) I have better and fun tools like blocswave, launchpad app and bm3.

            Cheers 😉

    • Spankous

      if you mean a wrapper in order to use 32 bit plugins in the 64 bit live, i purchased the “32 Lives” wrapper. Works flawlessly

      • Dave O Mahony

        Thank you Spankous! I will check that out and try it in 64bit Live9! Thanks!

  • Geeez, I thought that issue was long gone and forgotten? But it’s good to see this simple and concise wrap-up, Peter. I am amazed to read that still so many users do not run Live in 64-bit…

  • Bitwig Studio’s approach to the whole 32 vs 64-bit topic seems to be so much more effortless, elegant and innovative.

    • Whoa, wait a minute – innovative? There are a number of innovative things about Bitwig Studio (support for controller scripting, interesting ideas about merging touch input, support for expressive MIDI data), and indeed those have no direct equivalent in Ableton Live, but… 32-bit support? 😀

      So, there’s a reason for Ableton to avoid 32-bit plug-ins, at least in 2017. The odds of any well-supported plug-in not having been updated to 64-bit is essentially zero. This is a “shake the trees” moment – dump misbehaving plug-ins that may cause other problems.

      Keep in mind that for many plug-in developers, the 64-bit support process is “tick the 64-bit support box when you compile.” (It’s a little harder in some instances, but not by much.)

      • B.C. Thunderthud

        Yeah, but “well supported” isn’t necessarily the same thing as cool or useful. It’s important in expensive plugins but for free stuff it’s barely a consideration. I get that this has been inevitable for a long time but it does potentially mean buying replacements for a lot of stuff which still works perfectly well.

        • I’m curious which plug-ins you’re talking about.

          “A long time” is right. I think it’s been eleven years since I first covered Cakewalk’s move to 64-bit with SONARx64.

          And again, the payoff for that update is the ability to effectively use 8, 16GB, etc. RAM, and to crash less. I get that there’s some investment of time (and possibly money), but there’s some payoff as well. And if you don’t believe in effort to update software, then … this doesn’t impact you anyway, as the whole point is that it’s relevant only to an upgrade in the first place. 🙂

      • Thijs

        Isolating plug-ins in separate processes like BitWig Studio does instead of running them in the same process as the DAW like Ableton Live does is indeed more innovative.

        Retaining 32-bit compatibility is just a by-product of this level of isolation, it was never the goal in itself.

        • PaulDavisTheFirst

          See my comment up/down thread about scalability. What Bitwig does cannot scale.

          • Thijs

            Nonsense.

            First of all, by default, BitWig has one process for 32-bit and one process for 64-bit plugins. You can optionally isolate individual plugins that you found are crashy.

            Secondly, any overhead from this kind of process isolation is minimal as long as you know what you’re doing.

            With software any talk that “something will not scale” should be taken with a huge grain of salt as it’s either an attempt at FUD or simple ignorance.

            Have you actually tested what you’re talking about? Have you actually compared performance using the same project across the current versions of Live and BitWig? Where ate your results? How can we replicate them?

          • PaulDavisTheFirst

            I don’t even know where to begin. I wrote Ardour. I wrote JACK. I was doing multi-process audio routing and processing before Bitwig existed (and actually, pretty much before anybody else was doing multi-process audio at all).

            Context switches on modern CPUs consist of two components, one fixed cost (register loads) and one variable (TLB flushing and reloading). The latter is affected by the amount of memory touched by the process after the switch. The first cost is relatively cheap (on the order of 10 microsceonds) on modern processors. The second cost can be quite expensive, sometimes reaching 0.5msec. But let’s assume something more optimistic, say 20 microseconds per switch, total combined cost.

            Now lets create a session that represents a typical large format console, say, 48 channels. Lets put an EQ and compressor in each one. That makes 96 plugins, which in the worst case scenario implies 192 context switches per process cycle. That’s close to 4msec just for the context switches.

            What buffer size do you want to run your DAW with? How much DSP do you want to do? You’ve just used 4msec on context switches, with no signal processing at all.

            There are some ways to mitigate this cost, but ultimately if you want to scale up to the kinds of sessions used in (for example) movie post production, with hundreds of tracks and multiple pre- and post-fader plugins, the out-of-process approach cannot work.

            Obviously, if you’re willing to be limited to say 16 tracks with serializable plugins (not pre/post fader and no host-based processing between them), then sure, the “sandbox” model will work, and does provide crash protection. But I didn’t dispute that, I said it cannot scale.

          • Thijs

            I don’t doubt your qualifications, but you do seem to have trouble reading my comment, or considering the way BitWig handles plug-in isolation *in practice*.

            As I mentioned, BitWig only creates a single process for all 64-bit plugins and a single process for all 32-bit plugins. Nobody who uses BitWig is running every single plugin in a separate process and nobody was arguing that you should.

            This makes your argument more than a little bit academic. 🙂

          • PaulDavisTheFirst

            No, it’s not academic. Every time the processing “context” changes from the host (e.g. fader) to a plugin, a context switch is necessary. It doesn’t matter if it is always to the same process or to a different process.

          • Thanks for the explanation, Paul. Based on your description, my impression is that this could actually impact not only film score-sized works, but fairly typical electronic productions as they get more complex… does that sound feasible?

            To be honest, I have more experience with large, weirdly complex Live sets than I do Bitwig sets, so I don’t feel I’ve adequately tested this (either in my setup or anyone else’s). I do know even Richie Hawtin had at one point showed me a set he’d scaled up to something like 110 tracks (albeit lighter on plug-in use).

            It also seemed from the conversation with Ableton that in the end, they were seeing crashes as much from out of memory problems as from ill-behaved plug-ins. Maybe people are downloading fewer weirdo plug-ins these days… but that means that the direction taken by Ableton and the lions’s share of DAW developers makes more sense in the real world than sandboxing.

            (I got once taken to task back when I was writing at Macworld by a guy who had something on the order of 100 simultaneous tracks for recording a symphony orchestra… so I do recognize that there are some serious edge cases out there.)

          • PaulDavisTheFirst

            The main optimization that can be taken to reduce the overhead of sandboxing/out-of-process design is this:

            consider a track/channel/strip in which the signal flows through an EQ, then a compressor, then the fader. If the EQ is running out-of-process (or even in other hardware, like UAD or Waves SoundGrid) then theoretically at least there’s no need to return control to the host between running the EQ and the compressor … just let the signal flow take place in the “sandboxed” context and only context switch back to the host when they are both done. Now you’ve only got 2 context switches per “need to get to plugin context and run 1-N plugins in series”, rather than 2 per plugin.

            Obviously, this sort of signal flow is relatively common, especially in DAWs that have no facility for post-fader plugins. But all you have to do break that optimization in a given session/project is to insert any kind of non-sandboxed processing between the EQ and the compressor. Maybe some native plugin of the host, maybe the host offers a choice between sandbox/non-sandbox contexts for plugins, maybe something really simple that doesn’t look like a plugin. Any of these scenarios means that after the EQ runs, the signal must be processed by the host again before being given to the compressor, and the “optimization” is impossible. You’re back to 2 context switches per plugin.

            In addition, it isn’t clear (because the DAWs that use sandboxing are not open source and their developers don’t discuss this level of detail, in general) whether or not a given DAW has actually implemented the “optimization” in the first place. Architecturally it’s a lot simpler to design for the “worst” case – switch to plugin context, switch back, switch to plugin context, switch back – than to identify the cases where you do something smarter – switch to plugin context, run N plugins, switch back to host.

        • Bloink

          @disqus_NXb5OsHYkl:disqus
          Bitwig has _three_ separate settings, one where EVERY plugin runs in it’s own sandbox, one where all 32Bit and all 64Bit plugins run in one sandbox together and one where all plugins with the same Bit depth as the OS run inside the audio engine (the traditional way) and those with a different Bit depth run in another sandbox.

          @PaulDavisTheFirst:disqus
          As for scale: The more cores a system has, the better the one sandbox for each plugin actually scales (in Bitwigs reality, not in theory). With four cores, running all plugins in the audio engine performs best. With higher core counts, this shifts more and more towards the one sandbox per plugin. One guy having 24 cores/ 48 threads saw massive improvements in performance when using it.

          Overall:
          There is a major difference between a “static DAW” like logic, cubase etc. which are more recording/mixing/mastering oriented and “live DAWs” which are geared also towards live use on stage.
          A static DAW can be much more optimised, since everything that isn’t used ATM can be fully disabled. So those usually excel at hundreds of tracks and tons of plugins.
          Live DAWs like Live and Bitwig need to keep everything “on” since you want to be able to switch all tracks, devices and plugins etc. on and off as part of your performance without hickups and audio gaps. So they usually perform worse in general but also offer more flexibility.

          For the actual musician out there, well done sandboxing is a fantastic thing. Test a beta plugin, it crashes, you just restart it with a click of a button. BWS itself doesn’t crash.
          Even when running all plugins in the audio engine a plugin crash does not crash BWS, you can simply restart the audio engine. Your project is still there.
          I would happily give away some small amount of performance for having this.
          Airbags are a pain in the behind to build in, waste weight and space, but man are you happy to have them when you need them.
          Reducing this to pure theoretical performance gains is missing the point.

          And: In all my tests, Ableton Live never had any real performance gain over Bitwig Studio, no matter the plugin sandboxing. In one scenario it may have been something like 2-5% better, in others it was a bit worse by similar amounts.
          But Bitwig running modulation at audio rates and being much more flexible with routing and device order, I’ll happily give away another couple of percent of performance. 🙂

          And I’m sorry to say, but Jack for me is a major nightmare and I would call it one major reason why Linux for audio didn’t really lift off, so there’s that…

      • I guess @AmadeusPaulussen:disqus is also referring to the whole plugin sandboxing which doesn’t let the host application crash even if a plugin crashes. For me this “sandboxed” management of plugins sounds like the reason why they can support 32-bit and 64-bit at the same time, too. And both are great things.
        Ableton’s challenge still seems to be a huge legacy codebase that they’re only slowly starting to get rid of now (when was the last non-Push-related feature released again?).

        • Right, but I think that’s what the developers are saying here. This is one way of allowing them to develop that codebase faster.

          Of course, you also see the challenge they face from their own user base. People simultaneously want 100% backwards compatibility with everything, but they also want instant innovation.

          It’s actually not possible to do those two things simultaneously.

      • John Doe

        I think for many people, 32 bit plugins are still quite relevant.
        Yes 64 Bit software can allocate more memory, but if you happen to like the plugins from Krakli or Variety of Sound and many others, you may lose a lot. And those are _not_ the crashfest that common lore pins on them. 32 Bit plugins are _not_ more prone to crash than 64 Bit ones as such. Software has bugs, those need to be fixed, but this fairy tale of 32Bit = crashy is fake news.
        I also prefer the way Bitwig handles it, since I can use as much memory as I like while at the same time running whatever plugin I want. And if something should crash, be it 32 or 64 Bit, I can just restart the plugin in question.
        Every single 32 Bit plugin in Bitwig can use 4 GB of Ram in “Every plugin”-mode – no problem there.

        While I totally understand the decision from a business standpoint, it’s more about Live not having any adequate way of dealing with different plugins. Selling this to the user as a “feature” or “improvement” is a bit shady IMO.
        In the end it’s “deal with it, sucker” anyway 😉

        • Sure – if you can provide 64-bit memory space to 32-bit plug-ins, obviously, that’s better. But at the risk of stating the obvious, Bitwig were able to do that because they could start from scratch that way. Ableton – and not just Ableton, other DAW makers as well – built their plug-in architecture years ago.

          I think the question is, are there enough 32-bit plug-ins to justify building an entirely new plug-in architecture for Live from scratch?

          What I don’t get here in this thread is, people are simultaneously saying they want more new features from Live AND they want Ableton to rebuild the plug-in architecture for 32-bit plug-ins.

          Those are not to my knowledge mutually compatible ideas. 🙂

          • PaulDavisTheFirst

            Bitwig’s “plugin architecture” (running plugins in separate processes) is cool but doesn’t scale to sessions that are the equivalent of a large scale mixing console. You have to make a choice between sandboxing (e.g. Bitwig) and scalability. You can’t have both with current CPU and OS architecture.

          • Ah! I had a feeling there was some tradeoff here I didn’t know about. The problem is, you get more overhead with sandboxing?

          • PaulDavisTheFirst

            See the discussion with Thijs below/above this where I go into some detail about the overhead.

          • Ilia Bis

            FWIW, this technology is already available with Live if you use jbridge. I’ve found that the most reliable solution for me is to keep using the 32-bit version of Live while bridging some 64-bit as well as memory-consuming 32-bit plugins. Jdridge puts the plugins into separate processes (and gives further granularity of control, e.g. several instances of the same plugin can be grouped into one process, etc). This way I never run out of memory and can use all the legacy plugins without any problems (trying to do it the other way around — 64-bit host with bridged old plugins — proved less reliable).

          • John Doe

            It’s not 64-bit memory space, it’s each 32-bit plugin having it’s own full 32-bit space (hence the 4 GB) inside the overall 64-bit memory space…

            Well, I do not care that much what Ableton does, since it does not do what I want for a long time now. 😉
            So I’m using a host that does, and one part of that is that I can take my own time deciding if I want to keep 32 Bit plugins I happen to love and which will not be updated ever since the developer either died or went out of business or only does Synthedit plugins like Krakli. And I can do that with a well integrated and smoothly running bridge that just works.
            Live doesn’t even allow me to have more than one VST path, so it’s not really about rewriting their plugin hosting alone but simply being outdated even in the simple things, where multiple paths would allow me to point to a JBridged 32 Bit folder…
            And sandboxing has more benefits that just bit-bridging…

      • DPrty

        I have 32bit plugin’s I use everyday and they behave just fine. I will be deleting Ableton and keeping Reaper.

        • Daniel McKittrick Ramirez

          Live and Reaper are so insanely different. If Reaper works for you, Live was probably the worst possible DAW for your needs.

          • Ha, actually, I use both Reaper and Live. 🙂 But yes, I use them both because they’re different, so maybe only proving your point…

          • DPrty

            Sorry would have replied earlier but unfortunately the town I live in is burning down. Anyhow nice to take a break from the current local apocalypse and read cdm for a moment. Yeah they are very different I really liked them both but I have built many custom VST’s in 32bit and seem’s like it would be fairly easy for Ableton to just put a wrapper in place. Anyhow currently watching Bitwig and Reaper has a plugin something akin to Grid View to hold me through.

  • Ben

    Apple has already announced that after January 2018, they will no longer allow the signing of 32-bit mac apps. So no mac developers will be able to release 32-bit updates and sign their software. I believe MS has said they will follow suit. So it’s really out of developers hands at this point.

  • cooptrol

    What I would love is backwards compatibility when saving projects. It’s something pretty common in most design software, dunno why Ableton doesn’t have this feature yet…

  • itchy

    very excited for a more streamlined ableton . less is more with exceptions of course.
    very excited , less fragmented cleaner breath of fresh air

  • itchy

    would be nice to even go further and get rid of the suite version.
    one version of ableton and a trial version for noobs. keep all the sound libraries available on there site and download if you want them, but get all the devices. ok im gunna stop my self now before this goes on to a wish list.

  • Max

    Meh.
    What’s the fuzz about?
    I went everything 64 bits years ago.

  • Spankous

    version 10 would be nice. And if yes then i hope it better supports Vst3

  • steveoath

    Does no one use jbridge? Worked fine for me on 32bit plugins inside 64bit Ableton.

  • PaulDavisTheFirst

    As the developer of a DAW that runs on all 3 major OS platforms (linux, macos, windows), on all major CPU architectures (x86, x86_64, amd64, ARM and more) and all current notable word sizes (32, 64 bits), I’m here to tell you that the 32/64 bit issue is almost entirely a red herring.

    If you have code that relies on the size of a memory address, you have faulty code.

    If you are using a plugin API that relies on the size of a memory address, you’re using a faulty plugin API (here’s looking at you, VST 2.x)

    You won’t find anything in the codebase of Ardour (or Mixbus or Tracks Live or any other derivative of Ardour) that has to differentiate between 32 bits and 64 bits. The only difference are the compiler flags used to build the 32 bit or 64 bit versions.

    One more note, to help people grasp how big a 64 bit address space is; if you have a program which uses an additional 1MB every second, you won’t run out of address space before the end of the expected life of the sun. You might run out of physical RAM, of course, but the address space will still be there, ready to deal with more.

  • Elekb

    It was bound to happen sooner or later. Personally, besides the fact that I have less problems, dropouts and crashes when loading very large sample libraries, I did not see much difference in performance and stability between the 32 bit and 64 bit versions.

    I can see how this can be a problem for many people using third-party plugins still dependent on 32-bit. But obviously this depends on your workflow. When Ableton Live 64 bit first came out I began phasing out some of the third party plugins I was using and I now mostly rely on Live and Max for Live devices, with only a couple of 3rd party VST instruments that happen to be 64 bit and multi-platform.
    This process also had the liberating side effect of simplifying and cleaning up my workflow, which is mostly directed at live performance (although I can understand that people who do mostly studio work tend to rely on external plugins that to a better job than Live’s internal mixing and compression devices)

    If they are going to leave 32 bit users out cold, I really hope they are able to focus on solving some of Live’s remaining issues.

  • Guillaume Pervieux

    That also means that if you’re a windows user, forget about working with video : video handling for 64 bits with live (or with other software, btw) on windows is horrible.