ANY CODERS IN HERE??? HELP TAKE MATTERS INTO OUR OWN HANDS!

just an idea i had...

basically most of our complaints with the 1000 (excluding hardware related stuff like usb master/slave and whatnot) have to do with akai not wanting to implement features into os updates. zoning, actual editing in step edit, timestretch....etc. after emailing akai and recieiving their cut and paste answers of "maybe you should have bought a 2000xl or 4000" i realize that they really have no plans of making the 1000 as good as it could be. if its TOO good than why would people fork over money to get the other more expensive models (lets hear it for business strategies over customer loyalty).

well since the only thing holding us back is the OS, has anyone started to try and mess with modifying the OS code?

i mean WE HAVE THE HARDWARE WE NEED, we just need the right OS to let the 1000 do what it is really capable of.


stephen- i've seen you post some definitely valid info in this department as far as coding (not mpc wise but in general) and zoning and stuff. if any heads out there like yourself want to throw out some info here (have they attempted to even look at the code, is this too impossible of a dream in reality,etc....) it is more than welcome.


i just want to hear people's thoughts on this. so many things get hacked and modified nowadays, and the 1000 is the most friendly mpc hack wise.

so any people that know a little (or alot) about coding PLEASE SPEAK YOUR MIND. or maybe even try and take a look at the os. any info that you might gather (as basic as it maybe) is good info. i am horrible at coding stuff, so i'm throwing this out there to the people that are on top of their programming skills.

any info or discussion about this (whether its a realistic possibilty or not) should at least get some people thinking about it. maybe it can grow from there....



...and if this plan was something that actually materialized, we would finally be free from akai.

id like to say...to anyone that does this...has my full and total support...



if i knew how to work with coding...id be all over it...


if just a few people could work on the coding as a team it would end up beeing better then nobody...shoot, even just one person willing enough to work the coding would be good...we'd get further as time progressed and in the end we'd never look back...

Biggest problem with writing code for the MPC would be this: It would have to be completely re-written from scratch. Very doable, but in the short term, would make more headaches than it solves.

Reverse engineering embedded code is extremely painful, since you looking at the numbers that the processor inside the MPC decodes as instructions. THe code in the MPC is not very friendly like "when PAD is hit, then do this" type of thing. It is more like "0x01222, 0xFE45, 0x45AE".

Not saying it's not's *possible* that people could re-write the entire MPC code. But it would take a group of very dedicated people to do it. You'd probably see people port linux onto the MPC first...

Not being negative but it would be pretty hard to do. First you need to know what kind of processor they are using. Then you need their development tools. Without these its going to be real tough. If the processor is specially developed for akai then they would have their own in-house tools for development which means you can basically forget it! (real expensive)

What they should do is release the development tools and OS as open source and let people go to town on it. Then we would get some pretty cool things happening. But that's not going to happen any time soon.

Best solution is to hassle akai and make your own PC programs that work with the mpc. Kind of sux but what can you do?

the thing is, if you implement features that you find in the 2000 and 4000 models, what's the point in getting the more expensive models mpcs? Everybody would get the 1000 model, cheaper with lower margins, and that is dangerous for Akai.

Sure, we have the hardware, but I guess it's Akai policy to add features for more expensive models, it's called product line management.

What happens is that we like the 1000 model, and we know about the extra features of the higher models, but I guess that for many users, the 1000 model is a 1st mpc station, so we get to learn and enjoy it for a reasonable price, and when we are really hooked, then some of us will upgrade to the NEW 2000 or 4000 models that will pprobably hit the street in 6 months (my guess). It's called "managing the consumer to
1- get him in the product range and then 2- make him climb the product range to more profitable products.

You think I'm crazy? Well think how many entry level music gadgets you got, and then when you became really fond of it, you bought the new and higher model, and sold the old entry stuff you bought : I predict, in 6 months, the mpc 1000 will flod on ebay.

So, between you and me (and I wish I were wrong), there will never be a major OS update with time stretch, slice etc... UNLESS Akai wants to dramatically expand user base (ie increase market share), but given their policy of hi-end products, I think it is unlikely.

Off subject kinda but I bought a 1k not because its a 1st MPC(which it is for me) but for SIZE and USB. I do alot a traveling. I didnt want to lug a 2xl or 4k around not saying that it cant be done because people do it but I didnt want too.

besides, the 4k has a totaly different, more high-end sample engine. the 2k is an old machine that they shouldn't look back to. you realy can't compare them that way. so i don't see why they shouldn't give us the max for our money. what they actualy did considering the huge ram capacity. but i also have the feeling they dont want it to be too good.

and why do you think "they did not want it to be too good" ?
So that mpc 2000 buyers would still get the 2000 for its extra features,
and not the 1000.

Sure the machines are very different from each other,
but you do have low, mid and hi range and Akai has to manage perceived differences and values.

Whether Akai will develop significant OS upgrades depend on their
consumer attraction and migration policy within the mpc range.

Poll : for how many of you the mpc1000 is their 1st mpc station?

btw, I'm not related to Akai,
I'm just trying to imagine their marketing strategy.

if akai makes a mpc1000xl the the price of the 1000 will drop ALOT right??

no, they will probably discontinue the 1000 version to sell the xl.

henri sizaret: what you are saying is on point for the most part. i'm completely aware of the marketing/pimping principles behind akai's moves. its basic business that makes sense for them (not us).

i'm just still heated about them taking out moving events in step edit. that is just the most ridiculous example of them dumbing down the machine.
and i dont really feel like that it is some advanced extra feature.

they don't want to implement timestretch or zoning, then fine. i can get around this with my computer and some programs. those are "extra" features for higher models.

but moving stuff in step edit is not advanced or extra. i'm sick of cutting and pasting all day to clean up my sequences. thats what makes me heated. this is just some basic crap that they aren't going to add to an os because they want to sell their other crap.

i don't need a huge expensive mpc4000 and i dont want to deal with the 2000xl's zip scsi headache and slower load up times.

so overall this is where i am at now. frustrated....!

Hi,

I couldn`t agree more with you !
the points you mention reflect very tangible and desirable improvements!

I just wanted to cast a different light on the why`s and how`s on product lines and inspire some thoughts on why (or why not) some improvements might happen or not.

But at the end of the day, it`s the features that make us buy and stay with the product. And if Akai does not respond, there may be a risk that some of us would switch to... Roland (the SP 808 is not bad at all) who is rolling out nifty drum / sample stations.

Kind regards,

Henri

I'm sure most of us understand the marketing point of view.

jksuperstar wrote:Biggest problem with writing code for the MPC would be this: It would have to be completely re-written from scratch. Very doable, but in the short term, would make more headaches than it solves.

Reverse engineering embedded code is extremely painful, since you looking at the numbers that the processor inside the MPC decodes as instructions. THe code in the MPC is not very friendly like "when PAD is hit, then do this" type of thing. It is more like "0x01222, 0xFE45, 0x45AE".

Not saying it's not's *possible* that people could re-write the entire MPC code. But it would take a group of very dedicated people to do it. You'd probably see people port linux onto the MPC first...

Hmmmm.. i thing that it would be alot easier to do reverse engineering then writting the whole OS from scratch. First off all whit don't know the instructions that the CPU inside the MPC uses. Like : Additions, JUMPs, and manny others. Also, there are planty of HEX editors that could have been used to get the assembly code from the binary. What would really help, is someone who know abit about the hardware specs. Then with that wee could easilly find more info on the web.

Getting tools to program the thing, and disassembly are easy. GNU GCC supports the SH-? processors (which the MPC uses) very well. You could write any new code in C, and everything is nice. It would also be "easy" to figure what the address map on the SH-2 bus is (I have access to many high-speed scopes & logic analyzers). So you can find out where the CF card, A/D converters, effects chip, even the hard drive, are located. Just install the GCC suite, and try decompiling the .bin file from the latest release...everything we need should be in there (it may be compressed somehow, but judging on what functions are in there, the 500KB sized file is not unreasonable, so it might be just straight up machine code).

The difficult thing is understanding what the code is *doing*. reading assembler that contains NO variable names or function names, especially if the code was compiled with full optimization, is the painful part. It's not like your starting out with an .elf file or something that might store symbols in it. Your looking at raw machine code/assembley instructions with nothing but the SH's instructions & register names.