MPC Sample - Rumours & Leaks

jaymack wrote:Amazing how quiet it's been here the last 24 hours. Guess all the whining and moaning is going on at Gearspace

Ironically the Elektron site is one of the best MPC sites that I know of. Not too much whining and moaning. More like a chill cookout:
https://www.elektronauts.com/t/the-all- ... 40914/4003

Ultros wrote:now im taking a break lol... fkn uboot env is a lady's private parts to set up and im not motivated today. anyone else wanna join in? where's dustyslices... when we need him. he has the energy to go the distance.

oh God... seems like you don't like to waste your time, you crafty little xxxx
I'm trying to stay away from akai for a moment as there's a new fancy development for Ableton Move - "move everything / move anything" which makes me sit on the fence eyeballing the Move controller now.
That's why I want to wait a little until that 'mpc sample' circlejerk disperse a little
I'll have a look a the firmware in a minute but I hate to f**k around kernels tbf lolol

EDIT:
did you tried to binwalk it ?


a couple of errors as I was doing it in Windows WSL, I'll try later on on a proper linux laptop but it extracted some stuff:
180k kernel config
one .cpio archive (initramfs ?) and two other payloads (?)






EDIT 2:
Cheesus Crust - the main executable for that gadget is just a slightly modified 'normal' 116MB in size executable found in Live / X / One and it comes with all that garbage assets and spaghetti code written over the years

NearTao wrote:There's a handful of things that are fiddly here... but it's mostly a no nonsense experience where it either *does the thing* written on the tin or it doesn't.

* An xox/tr style sequencer might be nice... though for me it feels unnecessary
* The "step edit" needs some love to edit more than the velocity... slice/tune/length would all be nice
* "step edit" for note timing... struggling from the UI to figure out how to move a note...
* 16 levels feels like it needs a rework...
** tune needs to be able to specify the note... and adding root/scale options would be a welcome addition
** velocity/filter top half of the pads feel like they don't do anything...
** Adding in slice/start point would be a welcome addition (to me)
* Chops beyond 16 slices would open up a lot more workflows and make single pads have a lot more possibilities... though as is *does* work well enough
* Samples could use a *bit* more than just TRIM... some of the big brother MPC features like fade in/out, time stretch, normalize (though this *might* be in here), etc... would be welcome
* It'd be nice to have more than one Song slot... I think a lot of us will make multiple songs across the banks of samples... and we have plenty of sequences... I guess keep a notebook?

The list is mostly just little things... and we could see some of this land in a future update. Honestly a *lot* of the issues can be worked around by adjusting to the device's workflow and resampling... so I'm not even that worried about a lot of it.

Reminds me when they launched the 5000. Completely stripped down to just basic functions. Guess that makes sense for a product that they want you to upgrade to the more expensive ones

But everything you listed seems like it could be easily added in future updates. Pretty wild that step edit only has velocity…. With no grid how do you edit notes?

All those efx but you can’t apply them to individual sounds/pads? Is this correct?

NearTao wrote:There's a handful of things that are fiddly here... but it's mostly a no nonsense experience where it either *does the thing* written on the tin or it doesn't.

* An xox/tr style sequencer might be nice... though for me it feels unnecessary
* The "step edit" needs some love to edit more than the velocity... slice/tune/length would all be nice
* "step edit" for note timing... struggling from the UI to figure out how to move a note...
* 16 levels feels like it needs a rework...
** tune needs to be able to specify the note... and adding root/scale options would be a welcome addition
** velocity/filter top half of the pads feel like they don't do anything...
** Adding in slice/start point would be a welcome addition (to me)
* Chops beyond 16 slices would open up a lot more workflows and make single pads have a lot more possibilities... though as is *does* work well enough
* Samples could use a *bit* more than just TRIM... some of the big brother MPC features like fade in/out, time stretch, normalize (though this *might* be in here), etc... would be welcome
* It'd be nice to have more than one Song slot... I think a lot of us will make multiple songs across the banks of samples... and we have plenty of sequences... I guess keep a notebook?

The list is mostly just little things... and we could see some of this land in a future update. Honestly a *lot* of the issues can be worked around by adjusting to the device's workflow and resampling... so I'm not even that worried about a lot of it.

I watched you video nice review... although the Sample is not for me its a good tool.. I have a hard enough time starting and finishing a beat at home so getting the sample wont help at all just create another repository of unfinished ideas to never complete.

Now adding more features would take away what it was meant for.. its like if you want more spend few hundred more to get the MPC one.. this in my eyes is a intro to the real hardware thats why I cant call it a MPC.. Just Sample

Certified Beatz wrote:I watched you video nice review... although the Sample is not for me its a good tool.. I have a hard enough time starting and finishing a beat at home so getting the sample wont help at all just create another repository of unfinished ideas to never complete.

Now adding more features would take away what it was meant for.. its like if you want more spend few hundred more to get the MPC one.. this in my eyes is a intro to the real hardware thats why I cant call it a MPC.. Just Sample

I hear you... I've been getting a lot of questions about how it compares to the SP404 mk2... and to me they are hard to compare because they're both kind of distinct devices... but people are going to get wound up one way or another. I put the Sample in the "pairs incredibly well with a phone/tablet"... but I hear you... can only work with *so* much gear before you cannot keep it all in your head.

NearTao wrote:* "step edit" for note timing... struggling from the UI to figure out how to move a note...

The fader can adjust the note offset position . I'm surprised they didn't add a function to move the note . For example pressing down the B2 button could toggle velocity/position .
Even better , just by pressing the encoder and reserve B2 for automation, it might be complicated since there are multiple parameters per pad but by holding B2 the user could easily select from a list .

Speaking of automation , how does it work exactly ? Let's say you have automated 2 different parameters with K1 knob and you want to delete one . Holding delete and K1 gives you an option to what to delete or all automation is gone ?

Ultros wrote:The device name is called the AC50 using rockchip,rk3568 ...............

is this chip faster than the first live/mpc one ?
_____________________________________________________________

edit : when you are in chop mode , does it support loop mode ? Meaning if each chop can be looped . It also seems it lacks ping-pong mode looping . ( I'm reading the manual :p )

SakisX wrote:

Ultros wrote:The device name is called the AC50 using rockchip,rk3568 ...............

is this chip faster than the first live/mpc one ?

different specs / similar synthetic scores but this one runs 64 bits
https://gadgetversus.com/processor/rock ... ip-rk3288/

dustyslices wrote:

Ultros wrote:now im taking a break lol... fkn uboot env is a lady's private parts to set up and im not motivated today. anyone else wanna join in? where's dustyslices... when we need him. he has the energy to go the distance.

oh God... seems like you don't like to waste your time, you crafty little xxxx
I'm trying to stay away from akai for a moment as there's a new fancy development for Ableton Move - "move everything / move anything" which makes me sit on the fence eyeballing the Move controller now.
That's why I want to wait a little until that 'mpc sample' circlejerk disperse a little
I'll have a look a the firmware in a minute but I hate to f**k around kernels tbf lolol

EDIT:
did you tried to binwalk it ?

Code: Select alldagss@raider:/mnt/e$ binwalk -e kernel.fit

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             Flattened device tree, size: 2776 bytes, version: 17
2776          0xAD8           Linux kernel ARM64 image, load offset: 0x0, image size: 21692416 bytes, little endian, 4k page size,
288600        0x46758         SHA256 hash constants, little endian
11705048      0xB29AD8        ELF, 64-bit LSB shared object, version 1 (SYSV)
11715480      0xB2C398        SHA256 hash constants, little endian
11740608      0xB325C0        gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)
11790287      0xB3E7CF        Unix path: /sys/kernel/tracing
12016320      0xB75AC0        Base64 standard index table
12018192      0xB76210        SHA256 hash constants, little endian
12036440      0xB7A958        CRC32 polynomial table, little endian
12343275      0xBC57EB        mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 4bit
12344787      0xBC5DD3        mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 4bit
12346339      0xBC63E3        mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 4bit
12617091      0xC08583        mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
12703595      0xC1D76B        Neighborly text, "neighbor get requestrequest"
12703645      0xC1D79D        Neighborly text, "neighbor get request get request"
12703700      0xC1D7D4        Neighborly text, "neighbor get request"
12704049      0xC1D931        Neighborly text, "neighbor get requestrequest"
12704099      0xC1D963        Neighborly text, "neighbor get requestest"
12704145      0xC1D991        Neighborly text, "neighbor get request"
12704187      0xC1D9BB        Neighborly text, "neighbor dump requestbor dump request"
12704245      0xC1D9F5        Neighborly text, "neighbor dump request dump request"
12704300      0xC1DA2C        Neighborly text, "neighbor dump request attribute in neighbor dump request"
12704377      0xC1DA79        Neighborly text, "neighbor dump requestheader for neighbor table dump request"
12704451      0xC1DAC3        Neighborly text, "neighbor table dump requestbor table dump request"
12704509      0xC1DAFD        Neighborly text, "neighbor table dump request neighbor table dump request"
12704573      0xC1DB3D        Neighborly text, "neighbor table dump request"
12705232      0xC1DDD0        Neighborly text, "Neighbor entry is now dead"

WARNING: Extractor.execute failed to run external extractor 'lzop -f -d '%e'': [Errno 2] No such file or directory: 'lzop', 'lzop -f -d '%e'' might not be installed correctly
12875848      0xC47848        LZO compressed data
13585061      0xCF4AA5        Certificate in DER format (x509 v3), header length: 4, sequence length: 212
13585065      0xCF4AA9        Certificate in DER format (x509 v3), header length: 4, sequence length: 244
14022960      0xD5F930        Unix path: /dev/vc/0
14118464      0xD76E40        xz compressed data
14121634      0xD77AA2        Ubiquiti firmware header, third party, ~CRC32: 0x45430000, version: "STALE"
14235466      0xD9374A        Unix path: /sys/kernel/debug/dri.
14249624      0xD96E98        Neighborly text, "Neighbors]%s%s %pV"
14378157      0xDB64AD        PARity archive data - Index file
14567009      0xDE4661        Copyright string: "Copyright(c) Pierre Ossman"
14667328      0xDFCE40        Unix path: /sys/firmware/devicetree/base
14670385      0xDFDA31        Unix path: /sys/firmware/fdt': CRC check failed
14728513      0xE0BD41        Neighborly text, "neighbor table overflow!app_solicit"
16286732      0xF8840C        ASCII cpio archive (SVR4 with no CRC), file name: "dev", file name length: "0x00000004", file size: "0x00000000"
16286848      0xF88480        ASCII cpio archive (SVR4 with no CRC), file name: "dev/console", file name length: "0x0000000C", file size: "0x00000000"
16286972      0xF884FC        ASCII cpio archive (SVR4 with no CRC), file name: "root", file name length: "0x00000005", file size: "0x00000000"
16287088      0xF88570        ASCII cpio archive (SVR4 with no CRC), file name: "TRAILER!!!", file name length: "0x0000000B", file size: "0x00000000"
19120792      0x123C298       AES S-Box
19121048      0x123C398       AES Inverse S-Box
27715472      0x1A6E790       Flattened device tree, size: 60510 bytes, version: 17
27775984      0x1A7D3F0       Flattened device tree, size: 189 bytes, version: 17



a couple of errors as I was doing it in Windows WSL, I'll try later on on a proper linux laptop but it extracted some stuff:
180k kernel config
one .cpio archive (initramfs ?) and two other payloads (?)

Code: Select all 
dagss@raider:/mnt/e$ binwalk update

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             Linux EXT filesystem, blocks count: 27640, image size: 28303360, rev 1.0, ext2 filesystem data, UUID=4923824a-2756-40bc-a4e5-2ab71d771d77
28303360      0x1AFE000       Linux EXT filesystem, blocks count: 27908, image size: 28577792, rev 1.0, ext2 filesystem data, UUID=91f47b27-8623-4e4a-a952-d86aa2a2a2a2
56881152      0x363F000       Linux EXT filesystem, blocks count: 403988, image size: 413683712, rev 1.0, ext4 filesystem data, UUID=733f6d51-0383-4652-a857-7f258f0a8f0a


Code: Select alldata partition:
sudo mount -o loop,offset=56881152 update /your/path


EDIT 2:
Cheesus Crust - the main executable for that gadget is just a slightly modified 'normal' 116MB in size executable found in Live / X / One and it comes with all that garbage assets and spaghetti code written over the years

Haha nice one dusty! naw man i didnt binwalk it it was to be my next line of attack. thanks for the info here buddy thats awesome.

ill have a poke in a bit as well, lol i wonder if the executable will run on the mpc-one. it would save me a couple bucks lol.

Cubilas has already bricked his MPC Sample. He tried loading an XPJ from MPC3 and is now stuck in a boot loop, reflashing firmware hasn't fixed it.

https://www.reddit.com/r/mpcusers/comme ... pc_sample/

MPC-Tutor wrote:Cubilas has already bricked his MPC Sample. He tried loading an XPJ from MPC3 and is now stuck in a boot loop, reflashing firmware hasn't fixed it.

https://www.reddit.com/r/mpcusers/comme ... pc_sample/

Oh my god. that is a bad design flaw. I feel so sorry for this dude. sounds like he didnt do anything wrong. Send that ish back on warranty.

This happened to me with a baofeng uv5rm radio in the fall, ive been trying to hack my way into it ever since. the software skewed the settings and now its basically bricked stuck in a stupid password mode i cant correct. My heart sank when i did it. I got a spare to clone the data and fix it, still nada.. its a terrible feeling to brick something hours after opening it.

Its indicitive that digital stuff isnt always a good solution, its cheap to develop but its not reliable like classic analog mechanical stuff.

A good line of attack would be to unplug it and smash the power button a bunch and try to get all the power out of the devices so the ram state dies. ram as we know is volitile so removing the trickle of power that keeps it alive might be a avenue of attack.

that is assuming its even in-memory. i cant see how that could lead to any deeper i/o that does permanent damage unless he managed to buffer overflow it and really hurt it. I would imagine akai uses dynamic memory allocation like alloc, malloc or calloc to handle the project size in memory but if they used stack / heap and static buffers its potentially dangerous to load anything.

For example say you do unsigned char buffer[1024]; and shove 1025 bytes into that array, its an overflow that extra byte goes somewhere and its not always a good place. This is the basis for many exploits its how we hacked the sony psp so many times and is the base for "homebrew enabler". You can get arbitrary code execution by filling the 1024 bytes with padding and then adding a subroutine beyond that. Linux manages this with a "segfault" (segmentational fault). If you use stack allocation with too small of a heap size the code *can* end up being inserted into or over top of other assembly routines because the executable is actually placed into the ram, and the hooked by kernel to execute.

Now.. all that said. it's possible he overflowed into an adjacent library or or executables memory pool and that's not good. You might end up doing some i/o thats not intended.

I suspect this dude hasnt unplugged it and drained the power though and its just a state issue. invite him over here.

PS inMusic: i really need a job... help me out here ill stress test the piss outta your systems. i am about to be a free agent.

MPC-Tutor wrote:Cubilas has already bricked his MPC Sample. He tried loading an XPJ from MPC3 and is now stuck in a boot loop, reflashing firmware hasn't fixed it.

https://www.reddit.com/r/mpcusers/comme ... pc_sample/

Why did he think it was ok to do that? Akai clearly stated compatibility was coming later.

Ultros wrote:

MPC-Tutor wrote:Cubilas has already bricked his MPC Sample. He tried loading an XPJ from MPC3 and is now stuck in a boot loop, reflashing firmware hasn't fixed it.

https://www.reddit.com/r/mpcusers/comme ... pc_sample/

Oh my god. that is a bad design flaw. I feel so sorry for this dude. sounds like he didnt do anything wrong. Send that ish back on warranty.

This happened to me with a baofeng uv5rm radio in the fall, ive been trying to hack my way into it ever since. the software skewed the settings and now its basically bricked stuck in a stupid password mode i cant correct. My heart sank when i did it. I got a spare to clone the data and fix it, still nada.. its a terrible feeling to brick something hours after opening it.

Its indicitive that digital stuff isnt always a good solution, its cheap to develop but its not reliable like classic analog mechanical stuff.

A good line of attack would be to unplug it and smash the power button a bunch and try to get all the power out of the devices so the ram state dies. ram as we know is volitile so removing the trickle of power that keeps it alive might be a avenue of attack.

that is assuming its even in-memory. i cant see how that could lead to any deeper i/o that does permanent damage unless he managed to buffer overflow it and really hurt it. I would imagine akai uses dynamic memory allocation like alloc, malloc or calloc to handle the project size in memory but if they used stack / heap and static buffers its potentially dangerous to load anything.

For example say you do unsigned char buffer[1024]; and shove 1025 bytes into that array, its an overflow that extra byte goes somewhere and its not always a good place. This is the basis for many exploits its how we hacked the sony psp so many times and is the base for "homebrew enabler". You can get arbitrary code execution by filling the 1024 bytes with padding and then adding a subroutine beyond that. Linux manages this with a "segfault" (segmentational fault). If you use stack allocation with too small of a heap size the code *can* end up being inserted into or over top of other assembly routines because the executable is actually placed into the ram, and the hooked by kernel to execute.

Now.. all that said. it's possible he overflowed into an adjacent library or or executables memory pool and that's not good. You might end up doing some i/o thats not intended.

I suspect this dude hasnt unplugged it and drained the power though and its just a state issue. invite him over here.

PS inMusic: i really need a job... help me out here ill stress test the piss outta your systems. i am about to be a free agent.

It’s his fault. Why did he think he could load a mpc3 file into the sample? Akai stated this was coming later. It’s not currently a supported feature

J.O.BEATS wrote:It’s his fault. Why did he think he could load a mpc3 file into the sample? Akai stated this was coming later. It’s not currently a supported feature

That is a minor thing though, its not like he opened it up and started stabbing at its insides with a screw driver.

if it happened with an mpc3 project how can you be sure it wont happen with any other project?

Like imagine the user skews the project by tranfering it for back up. then later comes back and tries to load it and it bricks the system.

That's an inmusic problem not an end user problem. "appliance like" is a goal for us folks who code things because murpheys law is real.

Imagine how differently people would view me if my custom firmware for mpc bricked ppls stuff or my linux software were to ruin peoples computers, they would be right to be mad at me.

It should have project version detection that stops the end user from doing this to the device. Unless its intentional or overlooked.

You guys need to stop letting inMusic off the hook for things that you know is wrong. if you don't know its wrong.. SMARTEN UP. Stop being a fanboy and start being a mf G like you're supposed to. Neither tutor, dusty, kikgen, rvense or i are punks. Stand up for yourselves man.

My logic is if you take my money and **** me around, i am coming for you. to your home if i have to.

Grr my phones screen is cracked so i typo mad stuff.

Im not dick riding Akai, I have spilled plenty of ink calling them out

Sure, they should probably have realized dudes would try to load MPC3 projects into and so maybe could have built in a fail safe. But just like opening up the machine which it wasnt made to do you're risking something bad happening. Should I get mad at Akai for opening up my Live, **** something up and breaking it?

They clearly stated mpc3 compatibility was coming later, so why they hell would you try it knowing it isnt built into the OS? Do stupid things expect stupid results