MPC X, MPC Live, MPC One & MPC Key 61 Forum: Support and discussion for the MPC X, MPC Live, MPC Live II, MPC One & MPC Key 61; Akai's current generation of standalone MPCs.
User avatar
By Monotremata Thu Jan 19, 2023 6:43 am
HouseWithoutMouse wrote:Did the "big" 386 do the DSP and everything too? Having strict, even physical, separation between components does make it easier to reach stability, but more difficult to change the structure and add features. Making changes is kind of the enemy of stability, by definition.


Outside of the DSP stuff Im not sure but from the looks of it, it was running some sort of Intel x86 based OS for the whole thing. It only had one internal expansion and FX board, unlike the earlier ones that were all modular components. Used FAT32 as the native disk format and WAV files too.. Never seen the inside of the later Z series but I'd bet its even more so. It wasn't Windows or anything like that, so it seemed like it was still a pretty solid in house thing. Those were (still are) some killer samplers, but by then the computers had started taking over.
User avatar
By Telefunky Thu Jan 19, 2023 5:46 pm
Monotremata wrote:... Never seen the inside of the later Z series but I'd bet its even more so. It wasn't Windows or anything like that, so it seemed like it was still a pretty solid in house thing. Those were (still are) some killer samplers, but by then the computers had started taking over.

It‘s less... Z4/8 and MPC4k use a 32bit RISC CPU of type StrongARM SA1110.
Most of the bread&butter audio tasks are probably handled by a voice ASIC.
The digital audio section is impressive: asynchronous sample rate converters for both input and output, lots of PLLs. :smoker:
By Avasopht Fri Jan 20, 2023 2:19 am
HouseWithoutMouse wrote:Did the "big" 386 do the DSP and everything too? Having strict, even physical, separation between components does make it easier to reach stability, but more difficult to change the structure and add features. Making changes is kind of the enemy of stability, by definition.


More advanced CPUs can introduce variance in cache performance. That variance could lead to processes sporadically exceeding the update window.

Running lots of different plugins and processing algorithms could cause lots of instruction-Cache thrashing.

But that's not a problem caused by a lack of separation, but more a consequence of limited resources.

CPUs leverage a lot of sparse resources to yield disproportionate speedups. Cache gives a huge memory access speedup - but with a limited amount of memory. When used well, you can get all the benefits of having super-fast RAM without all of your RAM being super fast.

Those are the only types of instabilities that can really be attributed to using a SOC over dedicated DSP chips. Everything else is just bad application logic, which wouldn't have been helped by hardware (because the exact same logic would have been used).

I have noticed some dropouts when running lots of plugins alongside Stage Piano or Studio Strings. The CPU meter is always low - giving me the impression it might be a cache-related performance blip.
User avatar
By Monotremata Fri Jan 20, 2023 3:46 am
Avasopht wrote:I have noticed some dropouts when running lots of plugins alongside Stage Piano or Studio Strings. The CPU meter is always low - giving me the impression it might be a cache-related performance blip.


Hmm that could in fact be the CPU depending on what the meter is actually showing.. I have no clue how the meter in the MPC is running, but a lot of Ableton users freaked in between 10/11 when they switched the CPU meter to show the highest single load at any time.

Depending on what your mixer looks like, the CPU meter in Live is flipping out all over the place the entire time. You can take a 1 track project, load that track up with the right plugins and easily make the meter top out because it's only showing you the highest core. Cubase did the same thing and the meter in 12 bounces on me all the time up and down, especially when I start using Arturia stuff haha. You're never sure which track is running that high in Cubase, but in Live at least the tracks in the mixer have a little meter at the bottom that shows you each individual tracks load.

If they were to switch that back to the 'overall' usage, the meter would be a LOT lower and barely move, but you also wouldn't know when a single core maxed out and spiked because the meter would still be showing you the average across the whole board. You would just get a dropout or an overload and not think to check the load on the CPU. I have a feeling this is how Akai went with it.

Logic's CPU meter is the best. The one in the transport just shows you the average overall, but when you double click on it and open it in its own window, you get a meter for each core.
By jayneural Fri Jan 20, 2023 1:09 pm
For the instability topic : as long as it's software and not actual firmware inside, you'll always have some bugs.

Take a Roland product with those old school displays : this is firmware, the code talks very close to the hardware, no 15 layers between them, so less to no bugs

Take MPC, Maschine+ etc... there is a Linux under the hood, then drivers, development environment frameworks, you'll always have some bugs, maybe less than on a DAW with hundreds of plugins, but you'll always have some bugs.

Now you have to choose between close to a DAW functionality with the compromise of hitting a couple of bugs sometimes or more minimalistic workflow/features, close to no bugs.

Both models are efficient in their own way : the MPC because you have an actual UI to deal with, the more firmware oriented stuff that can give you headaches to use, however will almost always behave like expected.
By Hideous mutant Sat Jan 21, 2023 9:43 am
HouseWithoutMouse wrote:Close to DAW functionality... but way more bugs and problems. Why can Ableton make software where I don't have to be afraid of the whole thing crashing or every new version breaking things that used to work? Because they are better at making software.

Because they have built their software for more than 20 years. Reality check https://forum.ableton.com/viewtopic.php?f=1&t=131609
By HouseWithoutMouse Sat Jan 21, 2023 1:42 pm
So bugs are inevitably fixed when time passes, and new versions are increasingly stable and regressions get more rare, regardless of who is doing the development? That's not what it looks like with Akai.

I've been using Live since 2008, starting with version 7. Maybe I just don't remember the crashes, but the version 9 I'm currently using is extremely dependable. Maybe the relevant thing is to not update if it works.
User avatar
By Monotremata Sat Jan 21, 2023 3:45 pm
HouseWithoutMouse wrote:So bugs are inevitably fixed when time passes, and new versions are increasingly stable and regressions get more rare, regardless of who is doing the development? That's not what it looks like with Akai.

I've been using Live since 2008, starting with version 7. Maybe I just don't remember the crashes, but the version 9 I'm currently using is extremely dependable. Maybe the relevant thing is to not update if it works.


If it aint broke, don't fix it! :)

11 is pretty damn stable if you were considering upgrading. Owned it for about 2 years now, solid AF. Just don't use it much because I hate the mixer in it and the fact that everything in it is stereo/dual mono (gee kinda like the MPC). One thing I really like about Ableton, they aren't constantly pushing out a new version every year and actually working on the one they've got to make it the best it can be. Sounds like Steinberg took a cue and went this route for now. The old 'Cubase .5 release every fall' is gone now so hopefully Cubase 12 is going to be the best thing it can before they decide to put out 13..
By mpc_fan_2022 Sat Jan 21, 2023 8:20 pm
HouseWithoutMouse wrote:So bugs are inevitably fixed when time passes, and new versions are increasingly stable and regressions get more rare, regardless of who is doing the development? That's not what it looks like with Akai.

I've been using Live since 2008, starting with version 7. Maybe I just don't remember the crashes, but the version 9 I'm currently using is extremely dependable. Maybe the relevant thing is to not update if it works.


Ableton Live 9 is probably the most stable version of it. As soon as Max 4 Live became a requirement, the quality of the software took a noise dive. I don't like Max 4 Live, to me it's a co-opout from Live developers. Sure you can creator whatever you want now, but most M4L ensembles have terrible performances.

On the other hand, if AKAI open sourced MPC OS then you bet plenty of contributors would make the software much better in a heartbeat. Of course it will never happen, but I don't doubt someone else will offer a paid alternative OS eventually. AKAI sold wagons of MPC so there is a huge market for some $50 alternative OS that fixes every single bad stuff in MPC OS.
By Avasopht Sat Jan 21, 2023 8:45 pm
jayneural wrote:For the instability topic : as long as it's software and not actual firmware inside, you'll always have some bugs.


Hmm, that's not correct. There's nothing "special" about firmware, and it's most certainly not easier to create more stable systems with pure silicon.

There's a reason why Intel CPUs have a hidden CPU inside that runs on Minix OS.

jayneural wrote:Take a Roland product with those old school displays : this is firmware, the code talks very close to the hardware, no 15 layers between them, so less to no bugs

I've worked close to the hardware and written digital circuits from scratch.

It's much more error-prone to have to interact directly with the hardware as that dramatically increases the scope of development and loses the benefits of specialization and domain expertise.

There aren't many levels anyway.

You have the CPU. Your code runs directly on the CPU.

Writing in machine code is much more error-prone than writing in a high-level language like C++. It will also take much longer to develop software.

Your operating system adds, and they are stable. Nothing is lost by using Linux. There are only gains from using it.

An OS provides a layer of abstraction for accessing devices, but that layer of abstraction is pretty stable. It's why you can generally plug any class-compliant audio interface into a Mac and it just works. Right?

Leaky abstractions can introduce bugs, but the abstractions involved here aren't leaky. Any instability in the software comes down to logic flaws that would have happened if that same logic was applied to a firmware-based solution.

jayneural wrote:Now you have to choose between close to a DAW functionality with the compromise of hitting a couple of bugs sometimes or more minimalistic workflow/features, close to no bugs.

You can also have a minimalistic workflow/features running on software.

The problem is not the software, but the scope.

The Linux development environment is fine. I can use the exact same CLion IDE I use in Windows.

Those same features would have been just as buggy if they were done in firmware (quite possibly buggier as you wouldn't have the benefit of traditional development tools).
Last edited by Avasopht on Sat Jan 21, 2023 8:54 pm, edited 1 time in total.
By Avasopht Sat Jan 21, 2023 8:47 pm
Hideous mutant wrote:
HouseWithoutMouse wrote:Close to DAW functionality... but way more bugs and problems. Why can Ableton make software where I don't have to be afraid of the whole thing crashing or every new version breaking things that used to work? Because they are better at making software.

Because they have built their software for more than 20 years. Reality check https://forum.ableton.com/viewtopic.php?f=1&t=131609


It really comes down to priorities and resources.

They could have spent more time on QA to ensure the product is stable before releasing it. But that might mean it wouldn't have been released until 2023/2024 ;)
User avatar
By Neurone Sat Jan 21, 2023 11:12 pm
EnochLight wrote:Also, everyone waxes poetic about how "old hardware was more stable". Clearly they never worked on Ensoniq gear from the 80's and early 90's - that's what got me in the habit of saving my progress and saving it often (random OS crashes for no reason other than the wind blew in the wrong direction). :nod: :lol:

To be frank, the MPC of today is far, FAAAAAR more powerful & complex than they were 10 years ago, and even though there are some long standing bugs, I wouldn't trade my Live II or Force for any of that old stuff.


I had an ESQ1. Never failed me.
By jayneural Sun Jan 22, 2023 4:33 pm
Avasopht wrote:
jayneural wrote:For the instability topic : as long as it's software and not actual firmware inside, you'll always have some bugs.


Hmm, that's not correct. There's nothing "special" about firmware, and it's most certainly not easier to create more stable systems with pure silicon.

There's a reason why Intel CPUs have a hidden CPU inside that runs on Minix OS.

jayneural wrote:Take a Roland product with those old school displays : this is firmware, the code talks very close to the hardware, no 15 layers between them, so less to no bugs

I've worked close to the hardware and written digital circuits from scratch.

It's much more error-prone to have to interact directly with the hardware as that dramatically increases the scope of development and loses the benefits of specialization and domain expertise.

There aren't many levels anyway.

You have the CPU. Your code runs directly on the CPU.

Writing in machine code is much more error-prone than writing in a high-level language like C++. It will also take much longer to develop software.

Your operating system adds, and they are stable. Nothing is lost by using Linux. There are only gains from using it.

An OS provides a layer of abstraction for accessing devices, but that layer of abstraction is pretty stable. It's why you can generally plug any class-compliant audio interface into a Mac and it just works. Right?

Leaky abstractions can introduce bugs, but the abstractions involved here aren't leaky. Any instability in the software comes down to logic flaws that would have happened if that same logic was applied to a firmware-based solution.

jayneural wrote:Now you have to choose between close to a DAW functionality with the compromise of hitting a couple of bugs sometimes or more minimalistic workflow/features, close to no bugs.

You can also have a minimalistic workflow/features running on software.

The problem is not the software, but the scope.

The Linux development environment is fine. I can use the exact same CLion IDE I use in Windows.

Those same features would have been just as buggy if they were done in firmware (quite possibly buggier as you wouldn't have the benefit of traditional development tools).


I agree with your comments. Didn’t mean to say that closer to the hardware firmware development was easier and that couldn’t include bugs/code mistakes.

There our opinions totally join is that typically the scope of firmware of products like those old-school screen based Roland is pretty much set from almost the beginning. Of course they do add features later too, Roland proved that with their latest MV/MC/SP lineups, but I believe 90% of the final scope is planed right from the hardware design phase.

When you have a full blown OS and dev environment inside a groovebox which has an architecture close to a personal computer, that can easily incite you to go well beyond the intended scope.

Of course, I can say I enjoy both paradigms because I so much enjoyed how the modern MPC’s firmware has evolved in terms of features.

Not saying that having both myriad of features and stability is impossible, and certainly we can blame Akai for not reaching this, but unfortunately, when you think about brands who chose the same paradigm, I will only mention NI, it tends to rarely happen.
By HouseWithoutMouse Sun Jan 22, 2023 9:39 pm
Simple, hard interfaces between components tend to keep things clean. Even if marketing and management and programmers wanted to, they can't write a new feature that crashes your mixer, if the MPC is connected to it with analog cables. But inside the digital software box, everything is possible. Breaking anything is possible. There's so much rope, they can hang themselves many times over.