By MPC-Tutor
Fri Dec 01, 2017 1:25 am
EDIT: Ive re-written and updated all this here (includes some info now released by Akai):
http://www.mpc-tutor.com/how-much-memor ... ive-mpc-x/
I spent a bit of time today testing the MPC Live's memory usage, here's what I've found so far.
The first thing to realise is that when it comes to audio the MPC is specifically concerned with the 'length' of the sample, the frequency and the channels (mono vs stereo), but not the bit rate or format.
Apparently upon loading into memory, all audio is converted to 32 bit float, so it doesn't matter if the audio is 16 bit, 24 bit or mp3, once inside the MPC it is all treated the same and takes up the same amount of internal memory.
I created a bunch of 32 bit float audio files in Adobe Audition, each with a specific file size (500mb, 5 x 100MB, 50mb, 5 x 10mb,5mb, 2mb, 5 x 1mb and so on) and loaded them into a blank project. Eventually I found the MPC can load 1.128 GB of 32 bit samples, which means around 870MB is used to run the OS and MPC Software.
Note that it's not possible to claim the Live supports the loading of 'xxx MB of samples', because without knowing what bit rate the audio is, you cannot know how 'long' the audio actually is, and hence how much memory it will actually consume. For example:
500MB 16 bit/44.1 wav = 47 minutes stereo audio = 1GB of 32 bit audio converted in RAM.
500MB 24 bit/44.1 wav = 31.5 mins stereo audio = 667MB of 32 bit audio converted in RAM.
So if you are going to quote MB, you need to also confirm the bit rate (assuming it isn't a mixture of different bit rate files)
It's clearer to state that the Live can load up to 1 hour of stereo audio, i.e. 2 hours of mono audio into a new blank project.
Be aware that you cannot straight load a 2 hour file into memory, I think the MPC must use additional memory during the load process which is proportional to the file size being loaded, so you'll get a 'not enough memory warning'. So instead you have to load files in decreasing size - e.g. 500mb, followed by some 100mb, followed by 10mb, 1mb etc etc - there always has to be some spare memory available to act as a buffer.
I also experimented a little with the internal effects. After loading up 1085MB of 32 bit audio, I had approx 43MB of spare memory. I then added 4 inserts to 6 pads, 4 inserts across the program, and 4 inserts to a return before the memory gave out. That was using different effects (default settings) including some vintage effects. At this point I'd suggest effects do not use up much memory at all.
After receiving the memory full message, I took out one effect and then applied warp to the 6 samples in the DRUM program, but memory held out, so I suspect warping doesn't impact memory.
Additional DRUM programs seem to use up approx 3MB.
Not tested anything else, but so far I feel confident to say that when it comes to memory, don't be concerned about using effects, programs or warping, it's really just down to the length of audio you are loading, and do be aware that even though you might get a memory full warning this might just be the buffer overloading and there might still be room for some smaller files.
http://www.mpc-tutor.com/how-much-memor ... ive-mpc-x/
I spent a bit of time today testing the MPC Live's memory usage, here's what I've found so far.
The first thing to realise is that when it comes to audio the MPC is specifically concerned with the 'length' of the sample, the frequency and the channels (mono vs stereo), but not the bit rate or format.
Apparently upon loading into memory, all audio is converted to 32 bit float, so it doesn't matter if the audio is 16 bit, 24 bit or mp3, once inside the MPC it is all treated the same and takes up the same amount of internal memory.
I created a bunch of 32 bit float audio files in Adobe Audition, each with a specific file size (500mb, 5 x 100MB, 50mb, 5 x 10mb,5mb, 2mb, 5 x 1mb and so on) and loaded them into a blank project. Eventually I found the MPC can load 1.128 GB of 32 bit samples, which means around 870MB is used to run the OS and MPC Software.
Note that it's not possible to claim the Live supports the loading of 'xxx MB of samples', because without knowing what bit rate the audio is, you cannot know how 'long' the audio actually is, and hence how much memory it will actually consume. For example:
500MB 16 bit/44.1 wav = 47 minutes stereo audio = 1GB of 32 bit audio converted in RAM.
500MB 24 bit/44.1 wav = 31.5 mins stereo audio = 667MB of 32 bit audio converted in RAM.
So if you are going to quote MB, you need to also confirm the bit rate (assuming it isn't a mixture of different bit rate files)
It's clearer to state that the Live can load up to 1 hour of stereo audio, i.e. 2 hours of mono audio into a new blank project.
Be aware that you cannot straight load a 2 hour file into memory, I think the MPC must use additional memory during the load process which is proportional to the file size being loaded, so you'll get a 'not enough memory warning'. So instead you have to load files in decreasing size - e.g. 500mb, followed by some 100mb, followed by 10mb, 1mb etc etc - there always has to be some spare memory available to act as a buffer.
I also experimented a little with the internal effects. After loading up 1085MB of 32 bit audio, I had approx 43MB of spare memory. I then added 4 inserts to 6 pads, 4 inserts across the program, and 4 inserts to a return before the memory gave out. That was using different effects (default settings) including some vintage effects. At this point I'd suggest effects do not use up much memory at all.
After receiving the memory full message, I took out one effect and then applied warp to the 6 samples in the DRUM program, but memory held out, so I suspect warping doesn't impact memory.
Additional DRUM programs seem to use up approx 3MB.
Not tested anything else, but so far I feel confident to say that when it comes to memory, don't be concerned about using effects, programs or warping, it's really just down to the length of audio you are loading, and do be aware that even though you might get a memory full warning this might just be the buffer overloading and there might still be room for some smaller files.
