Glitching and popping and locking up my mpc one

I was hoping the new firmware would fix this but this is f***ng up my life rn.

Not even 2 hours into any new project, the thing gets up to 90% cpu while its doing nothing. I dont even have any sequences or tracks loaded, just programs. Editing samples into slices, into programs.. it doesn't matter what im doing though.

Seems kinda defective.. let me see if i can post a video rather than explain…

https://youtube.com/shorts/8oabt7rqA1Y

https://www.youtube.com/watch?v=K4fD2p4RmX0


* i dont think you can tell from the video, but the added annoyance is this soft pop from the line-out.. and every time it pops the tap tempo light blinks 3 to 13 times..

Reboot puts it back to normal, until i do anything, then

Avoid using the internal storage , it seems almost maxed out

You have too many Projects/Samples that you saved on your Internal Drive. I suggest opening each Project one at a Time, and saving them to an External Drive/SD Card/etc. Then Delete each of those Projects from the Internal drive. DO NOT DELETE ANY PRE-LOADED CONTENT. Because you'll be back here saying my MPC isn't working right after i Deleted everything. "Does anyone have the MPC Preloaded Content Files?"

Erratik wrote:Seems kinda defective..

The internal memory should not be saved onto.

Use external usb stick/hdd/ssd.

Leave the internal memory alone.

Sequences and tracks don’t take up much memory at all.
Samples take up memory. Samples.
.

double tap the stop button. it will stop all play back (even the stuff you cant hear) watch the cpu indicator while playing. stopping. and then stopping all with double tap.

also putting different fx on individual pads has varying results on cpu. if you overload the pad program with cpu intense plugins that will cause your cpu to max out. Once you create a program with all the fx applied to your kit bounce it again to 16 one shots and chop it and create a final program for saving. so your mpc isnt doing fx processing on the 16 samples each itteration. Does change the effect a bit but still comes out good.

Ultros wrote:also putting different fx on individual pads has varying results on cpu. if you overload the pad program with cpu intense plugins that will cause your cpu to max out. Once you create a program with all the fx applied to your kit bounce it again to 16 one shots and chop it and create a final program for saving. so your mpc isnt doing fx processing on the 16 samples each itteration. Does change the effect a bit but still comes out good.

In this case I hadn't evn go t as far as to go into any effects, but I will note that for the future.
Ive been curious about if its better to make programs by the non-destructive slices method, or with individual samples, like previous mpcs.. I usually opt for the slices because its less files to manage and was always plagued with one or two files that wont load on my 2000xl. Also, Even on the MPOC one I am getting a lot of "this sample is already loaded" for anything with the same file name.. thats really a pain when you load a drum and it breaks your synth pattern. I hope Akai can find a solution for that, as well as the copying every sample from RAM into every new program. I guess its fine as soon as I do what everyone else is saying and free up my internal drive for scratch disk space or whatever.. if they Akai didn't want me to use it why did they give me access to it? smh

SakisX wrote:Avoid using the internal storage , it seems almost maxed out

Thanks! Yeah I was thinking it could be something along those lines and was able to free up quite a lot by moving the first handful of projects i made on to an external drive. This was effective once i found the check box that un-hides project files. Sneaky one, Akai..

My first 3 projects essential filled up the drive, because just learning, i wanted to load all the factory stuff into one program. If i got 2 GB RAM i want to use 2 GB RAM. If you dont' understand, you never had to work with 16MB ram.. Anyway the goal is to do 60-90 minute live-pa from my productions rather than as an afterthought. I'm somewhat intentionally stress-testing it -- but this issue is a bit surprising because why the CPU climbs and site dont make sense. RAM leaks I somewhat have a working knowledge of, but a CPU leak sounds like something that could eventually damage the hardware. Also, its very annoying.

I haven't done anything really heavy since freeing up the space so i can't say for sure if it had impact yet, but my uptime is now at about 24 hours and just with an empty project and a few pgms loaded, im not hearing or seeing it freak out on me.

If they were going to limit the internal space like that they really should have made room for another drive. Even though you are working eith everything in the RAM anyways, i would like to have enough space to at least load some expansions and their new plugins.. it would be best to only save projects externally so if some bum stumbles into your studio and pulls your usb you dont have a broken project AND a bum in your studio. Maybe MPCstuff has a solution for that .. ... .. surprisingly I am not seeing anything for it.

If anyone has any info on the internal drive, drive type, how to get to it without breaking everything..
Please let me know. If they have 7" replacement screens at mpcstuff but not hard drives, im gonna guess its soldered on to the board or something. That would be totally lame.

Lampdog wrote:

Erratik wrote:Seems kinda defective..

The internal memory should not be saved onto.

Use external usb stick/hdd/ssd.

Leave the internal memory alone.

Sequences and tracks don’t take up much memory at all.
Samples take up memory. Samples.
.

Ok, I'm an IT guy. For 30 years now. . I kind of understand the answer to my question but still have to ask it -- since i know windows and mac computers use the hard drive for page files scratch disks / temporary space for stuff in the working RAM. My answer to that - Akai should have thought of that before they gave me 2 GB RAM and barely that much free space to work with. How is not every mpc one user not running into this before finding their way here?

Anyways thanks for the input!! Back to the music, until something else breaks and needs tech support.
On that note (iso - cheep, reliable firewire 400/800 or 400, or 800 card)

Erratik wrote:My answer to that - Akai should have thought of that before they gave me 2 GB RAM and barely that much free space to work with. How is not every mpc one user not running into this before finding their way here?

Before buying Mpc One I searched this forum and read about the "not saving to the internal disk", most people have bought a large sd card ,so I ordered a 128G sd card

Erratik wrote:If anyone has any info on the internal drive, drive type, how to get to it without breaking everything..
Please let me know. If they have 7" replacement screens at mpcstuff but not hard drives, im gonna guess its soldered on to the board or something. That would be totally lame.

It's simply a micro SD card , I think @Ultros has replaced it with a bigger one ,can't remember if he simply cloned the card and extended the partition or anything more technical
you need to find info on opening the mpc one (warranty?) , I'm 100% there are photos posted here in the forum somewhere

My One has the same problems above as I brought up in another thread. Using an external drive hasn't fixed this problem for me at all. The double tap stop option as suggested here is the only temporary solution for myself for the time being.

Be worth opening her up and checking connections.

Mikrogenik wrote:My One has the same problems above as I brought up in another thread. Using an external drive hasn't fixed this problem for me at all. The double tap stop option as suggested here is the only temporary solution for myself for the time being.

maybe your MPC has a completely different problem hardware related , but simply using an external sd card doesn't help if the internal is almost full (you also need to free space)

Quick Update:

I am still able to reproduce the problem, unfortunately. Fortunately -- I remembered the "double-tap" suggestion made here, and that works!
That is a whole lot easier than trying to finish what im doing with the glitching until i go mad and reboot, loose everything i didnt save.

I wasn't paying enough attention to tell if it was instant, but after tapping on stop the cpu went back down to 27% and my monitors are not making noise except when i make it. This will do, for now.

I'm not sure what it has to do with but maybe we can get a better idea if we compare what we are doing when it goes looney. It is fine for me if i startup, load a project and do whatever, but when i get into a choppin n slicing mode and load some loops, cut into new pgms.. after about 10 or so it just can't hang.
That also had me thinking about the slicing versus chopping when you make new pgms. which is easier on performance? I am thinking that the old way of cutting each to a new sample is still best because it seems like having to keep track of these cue points might be whats pushing the CPU up in the first place. if it just has to call a small sample from memory on each hit, its less work for sure. The number of samples in ram doesn't matter as much as keeping the overall file sizes down.
I'm going to see if it makes any difference if i only use chopped pgms, no sliced samples.
I would think that if you only use one 16 measure sample, and slice it into 32 pads -- that the mpc would only have to load that one file into ram, and it would be easier on performance. The way its acting, it seems more like its loading the same sample 32 times. If you make multiple pgms using the same 16-measure sample, and you change a location of a slice while editing one, it changes it on the other pgm too. so the slice points are added on to the samples, not attached to the pgm -- not sure i like that.

This is all just a bunch of non-sense, I have no clue what im talking about.. but if you have an opinion feel free to share it.

Erratik wrote:Quick Update:

I am still able to reproduce the problem, unfortunately. Fortunately -- I remembered the "double-tap" suggestion made here, and that works!
That is a whole lot easier than trying to finish what im doing with the glitching until i go mad and reboot, loose everything i didnt save.

I wasn't paying enough attention to tell if it was instant, but after tapping on stop the cpu went back down to 27% and my monitors are not making noise except when i make it. This will do, for now.

I'm not sure what it has to do with but maybe we can get a better idea if we compare what we are doing when it goes looney. It is fine for me if i startup, load a project and do whatever, but when i get into a choppin n slicing mode and load some loops, cut into new pgms.. after about 10 or so it just can't hang.
That also had me thinking about the slicing versus chopping when you make new pgms. which is easier on performance? I am thinking that the old way of cutting each to a new sample is still best because it seems like having to keep track of these cue points might be whats pushing the CPU up in the first place. if it just has to call a small sample from memory on each hit, its less work for sure. The number of samples in ram doesn't matter as much as keeping the overall file sizes down.
I'm going to see if it makes any difference if i only use chopped pgms, no sliced samples.
I would think that if you only use one 16 measure sample, and slice it into 32 pads -- that the mpc would only have to load that one file into ram, and it would be easier on performance. The way its acting, it seems more like its loading the same sample 32 times. If you make multiple pgms using the same 16-measure sample, and you change a location of a slice while editing one, it changes it on the other pgm too. so the slice points are added on to the samples, not attached to the pgm -- not sure i like that.

This is all just a bunch of non-sense, I have no clue what im talking about.. but if you have an opinion feel free to share it.

You haven't mentioned if you now have free space on the internal sd card , after that reinstall the OS and reset preferences