64bit Live ...

[aleme]

When?

I dont care when 9 will be out. But I want to know when a 64 bit version will be available.

And there is absolutely no logic telling me to wait until 9 comes out.

[simpleton]

Aint gonna happen before Live 9. And that is at least 6 to 7 months away.

[d-track]

http://youtu.be/waacof2saZw

[Piplodocus]

http://youtu.be/waacof2saZw

lol

[Piplodocus]

http://youtu.be/waacof2saZw

lol

[kent_sandvik]

64-bit for DAWs is not overhyped:

* Film scorers need huge address spaces for handling large amounts of samples triggered. For them a 64-bit application is close to a must today.
* With tight laptop systems with let's say 3Gb max real memory the VM starts to work really hard with 32-bit address spaces resulting is poorer performance.
* And if more than 4Gb of memory, there's little benefit running 32-bit apps in such runtimes with the additional memory.
* It hides and postpones issues with large amounts of memory objects in memory resulting in lots of paging, or at least hides memory leaks from crashing a system. If Ableton live is memory-leak free, not sure all plug-ins out there are so.
* Hardware works much better with 64-bit address spaces so it could use natural data bus fetches and so on.
* Many new plugins, especially mastering ones, operate in 64-bit mode for handling huge dynamic ranges. If the DAW operates in 32-bit mode there's a lot of shuffling data back and forth between 32-bit and 64-bit mode. Makes it all slower.
* With the MacOSX runtime, VM is 4Gb but due to wired memory the real number for max range of memory addresses is just below 3.2Gb so that limits a lot of issues related to performance and running out of address space resulting in more paging. In 64-bit mode the memory address range is astronomical, we should not hit that one for 20+ years or more.
* Many Intel instructions use 64-bit registers as their natural format for operations.... Need I say more.

It's close to a checkbox item with most DAWs today due to those issues and much more. But what do I know, I just programmed a 6809 to do MIDI sequencing back in 1983 so I tend to be an 8-bit guy myself.

[glitchrock-buddha]

Well, there's another thing to consider...

Although Live & Max are "tied" into each other one environment can be individually developed. However, I know that Max 6 won't be 64bit when it comes out. And quite frankly (though this is speculation on my part) I doubt that one product would go 64bit without the other.


Personally I don't care either way, IMO the whole 64bit thingie is way overhyped. People start making up stories as if you simply can't address more memory without going 64bit but quite frankly that's bollocks. People always mistake direct addressing with indirect addressing, and the latter is very often used within programming.

I mean; 16bit (the old 8086 CPU's) means you can only address 64kb of memory at once. As such a 16bit applications could only use 64kb, right? Wrong. Something which has always been clearly demonstrated wrt .exe files vs. .com files (my main reference is the Intel platform here).

Oh; and lets also not forget that in those days we had a whooping 640kb worth of memory While on the 16bit era, only 64kb directly accessible ?

Still; making a .com file was relatively easy with assembler. Start debug, use 'assemble' and start typing. The "write" command was all you need to write it to disk and you were done. Only problem; you could only address 64kb at once.

BUT... .exe files otoh were able to go way beyond that. Basically because one .exe file consisted of several regions within the same program, all 64kb chunks which were "mapped together".

I'll spare you the specific technical mumbo jumbo but in the end the results were simple; although 16bit would only allow direct access of 64kb, programs could easily address 128kb, 1Mb and more. Later we got 32bit, more memory, sure, and the range of direct memory access was raised to 4Gb.

Although much has changed in the mean time the small detail wrt. direct vs. indirect access hasn't. Pentium Pro for example (around the end of the era where I started paying more attention to all this)... 32bit machine with an external data bus of 64bit. And that's not only talking speed here.

64bit sounds very cool and all but honestly; its also majorly overhyped. Don't forget that there's always a marketing scheme brewing these days and 64bit "sells".

What are you going on about. It's much more simple than that:
64 bit will be a huge advantage for several reasons:
-For ram hungry plug-ins like Omnisphere, using many instances quickly approaches the limit to what Live can handle, making it unstable. This is not hype, this is how it is.
-The those large detailed sample based instruments, even one or two of these can max out Live's RAM usage if the plug-in or device doesn't have a memory server.
-Currently it is difficult to use one Live instance for your whole set (ie. containing multiple songs) when you use realistic sampled instruments or ram hungry devices (like Amplitube 3) becuase it has to load the ram and deactivating devices doesn't offload the ram.

It may not be an issue if you use primarily synthesis or loops but many plug-ins take significant ram these days and DAWs need to keep pace with the technology to make them useable. Live doesn't do well using over 2gb of ram and that just isn't enough these days and should not be a limit. This is far more important than 64 bit audio processing which was pretty much completely marketing and to make people happy who like to fool themselves about sound quality "improvements".

[Bizon]

Well, there's another thing to consider...

Although Live & Max are "tied" into each other one environment can be individually developed. However, I know that Max 6 won't be 64bit when it comes out. And quite frankly (though this is speculation on my part) I doubt that one product would go 64bit without the other.

Never really considered this. Good point.

Not sure how they plan to get around this.

[HeadrickProductions]

Well, there's another thing to consider...

Although Live & Max are "tied" into each other one environment can be individually developed. However, I know that Max 6 won't be 64bit when it comes out. And quite frankly (though this is speculation on my part) I doubt that one product would go 64bit without the other.

Since I don't use max I did not know that the new version is not 64 bit. Since i'm ignorant in this area can live not evolve to a 64 bit program without max changing as well.

If this is the case then MFL will really slow down the Live updates. That could be a good thing as far as Ableton taking longer to work on releasing updates.

They also have to deal with Serato updates as well.

It makes sense that it might be a while before we see 64 bit, but I hope your wrong


Oh yeah and 64 bit, try using a bunch of east west stuff, heavy reaktor stuff, etc and you'll greatly appreciate what you can do in 64 bit DAW's that you can't do in live

[Slightlydelic]

i find it quite easy to run out of memory in ableton, infact its the only time live crashes for me. i would love a 64 bit version i could run more than 4 gig of ram in.

i know its just the way i choose to work that gets the out of memory crashes happening, but i dont realy want to comjpromise the way i work.

if it was a case of running out of tracks and cpu issues i would have no problem upgrading my laptop to a higher spec, but right now the problem is not enough memory and thats somthing i need ableton to sort out, with a 64 bit version, whether its in live 9 or not i cant wait for it to come, its by far the feature/update i want the most.

[Joghurt]

Max 6 will have 64 bit Audio!

[nuxnamon]

correct me if I'm wrong, but won't Live becoming 64bit also benefit people with multi-core/processor systems on OSX enabling Grand Central dispatch resulting in a significant CPU improvement. can someone chime in on this or did i read that wrong... I think that and the RAM issue is what i am most waiting for..

[kent_sandvik]

correct me if I'm wrong, but won't Live becoming 64bit also benefit people with multi-core/processor systems on OSX enabling Grand Central dispatch resulting in a significant CPU improvement. can someone chime in on this or did i read that wrong... I think that and the RAM issue is what i am most waiting for..

GCD could work with 32-bit applications, so this is separate from the 64-bit address space. I suspect Ableton Live is written with cross-platform in mind so they use Posix threads, but if they used GCD for sync locks and so on they could indeed get a nice performance boost as well as not balance their threads across cores.

[dbfs]

Well, there's another thing to consider...

Although Live & Max are "tied" into each other one environment can be individually developed. However, I know that Max 6 won't be 64bit when it comes out. And quite frankly (though this is speculation on my part) I doubt that one product would go 64bit without the other.


Personally I don't care either way, IMO the whole 64bit thingie is way overhyped. People start making up stories as if you simply can't address more memory without going 64bit but quite frankly that's bollocks. People always mistake direct addressing with indirect addressing, and the latter is very often used within programming.

I mean; 16bit (the old 8086 CPU's) means you can only address 64kb of memory at once. As such a 16bit applications could only use 64kb, right? Wrong. Something which has always been clearly demonstrated wrt .exe files vs. .com files (my main reference is the Intel platform here).

Oh; and lets also not forget that in those days we had a whooping 640kb worth of memory While on the 16bit era, only 64kb directly accessible ?

Still; making a .com file was relatively easy with assembler. Start debug, use 'assemble' and start typing. The "write" command was all you need to write it to disk and you were done. Only problem; you could only address 64kb at once.

BUT... .exe files otoh were able to go way beyond that. Basically because one .exe file consisted of several regions within the same program, all 64kb chunks which were "mapped together".

I'll spare you the specific technical mumbo jumbo but in the end the results were simple; although 16bit would only allow direct access of 64kb, programs could easily address 128kb, 1Mb and more. Later we got 32bit, more memory, sure, and the range of direct memory access was raised to 4Gb.

Although much has changed in the mean time the small detail wrt. direct vs. indirect access hasn't. Pentium Pro for example (around the end of the era where I started paying more attention to all this)... 32bit machine with an external data bus of 64bit. And that's not only talking speed here.

64bit sounds very cool and all but honestly; its also majorly overhyped. Don't forget that there's always a marketing scheme brewing these days and 64bit "sells".

Look closely kids - This is a perfect example of someone who has no fucking idea what they are talking about. Mindless ramblings... Lay off the elmers glue dude..

It's shocking that people still have no idea what the fuck x64 means to them, yet these are the same shit stains giving out advice to people...

Lets simplify it for the retards.

64 bit OS = supports up to 192GB of RAM - Thats right.. One hundred and ninty two GIGABYTES!
32 bit OS = supports up to 3 to 3.5GB of RAM (More like 3.25) - And good luck running a stable system maxing out 3GB of RAM.

64 bit PROGRAMS = Able to access and use 192GB of RAM
32 bit PROGRAMS = Able to access and use 2.5 to 3.25GB of RAM - And that is being generous for Live.

Theres no fuckin marketing ploys. No secret information being witheld. No conspiracy theories about x64. Its just more fuckin power for you and me in the end. And anyone whos claming its "overhyped" seriously needs to be spayed and neutered so that they dont reproduce any more retards that want to give advice about shit they know nothing about.

[Tone Deft]

chill man. you might disagree with Shell but he's a good guy. a little mutual respect does a lot more for a conversation than unnecessary personal attacks. you might not like what he said but IMO he knows the geekshit better than most users on this forum. cut him some slack and good things can come of it. there's no need for that kind of rant. frankly it makes you look bad, feel free to edit it.