By flashtheproducer
Fri May 04, 2007 11:30 pm
Hi friends,
I have a suggestion/question. Being in the software business much of my like, I am familiar with (as many of you are) the process of improving software.
It is no secret that the MPC500 has a lot of potential, and leaves a lot to be desired in the user-interface department. And, there are many things we could "wish for" that would be new in forthcoming software updates.
For the purposes of this email, I will call those completely new things "New Feature Requests", and I will ignore them for the moment.
Having set them aside, there usually are two other kinds of requests, namely, "Feature Modification Request" and "Bugs". Respectively, these usually are described as 1) things that work, but don't work in the way one would like them to work, and 2) things that just don't work at all.
As an example of an "FMR" we might ask for the list of sample-names to return to the sample-name just assigned to a pad, instead of the current way that it returns, taking you back to the top of the list of samples. It isn't a bug per se, because it does work, -just in a poorly designed manner. This would be an FMR.
An example of a bug might include some of the things we see in the forum where things just do not work at all (I won't cite one at this time). But suffice it to say things that can cause a hang, lost data, or a crash generally qualify.
And lastly, there is poor documentation that can contribute to all of the above, that is, if the freakin' docs were better, we might "get it" better
Having said all this leads me to my real point.
I am reasonable sure Akai wants to see the '500 be a successful product. And, I am also sure that without addressing some of the FMRs, Bugs, and Documentation issues, they seriously limit their odds of great success with the unit.
So,...... I was wondering if we might want to maintain (and moderate) three topics on this forum, and, have someone (one of the moderators?) actually contact Akai Pro's USA office and invite them to participate in the forum, and create a bridge between "us and them".
The reason I think the 3 threads must be moderated, is because I think that for Akai to seriously respond to our input, we need to be sure that anything "sent" to them meets some basic criteria, such as:
For bugs: there must be a clear written explanation as to how to consistently reproduce the problem (software engineers can't fix what the can't reproduce)
For FMRs: there must be a clear written explanation of the requested software behavioral change in context of how it works currently. (Software engineers need a "spec" or "requirements statement of some kind before they can evaluate "how to implement" any request for change.)
For example, I might request as an FMR that when entering a new name for an extracted sample (following a TRIM-menu operation) that the cursor keys work even before I have moved the cursor with the locate keys. (Ever notice that once you move the cursor with the locate keys, only then does the cursor key(s) work [maddening!].
SO, if you've made it this far, and have an opinion, please post it.
And, if you're a moderator and feel that we could provide Akai with meaningful, qualified, feedback, and that someone "here" could contact them to measure their interest in the idea, that'd be great!
Thanks All!
-FlashTheProducer
I have a suggestion/question. Being in the software business much of my like, I am familiar with (as many of you are) the process of improving software.
It is no secret that the MPC500 has a lot of potential, and leaves a lot to be desired in the user-interface department. And, there are many things we could "wish for" that would be new in forthcoming software updates.
For the purposes of this email, I will call those completely new things "New Feature Requests", and I will ignore them for the moment.
Having set them aside, there usually are two other kinds of requests, namely, "Feature Modification Request" and "Bugs". Respectively, these usually are described as 1) things that work, but don't work in the way one would like them to work, and 2) things that just don't work at all.
As an example of an "FMR" we might ask for the list of sample-names to return to the sample-name just assigned to a pad, instead of the current way that it returns, taking you back to the top of the list of samples. It isn't a bug per se, because it does work, -just in a poorly designed manner. This would be an FMR.
An example of a bug might include some of the things we see in the forum where things just do not work at all (I won't cite one at this time). But suffice it to say things that can cause a hang, lost data, or a crash generally qualify.
And lastly, there is poor documentation that can contribute to all of the above, that is, if the freakin' docs were better, we might "get it" better
Having said all this leads me to my real point.
I am reasonable sure Akai wants to see the '500 be a successful product. And, I am also sure that without addressing some of the FMRs, Bugs, and Documentation issues, they seriously limit their odds of great success with the unit.
So,...... I was wondering if we might want to maintain (and moderate) three topics on this forum, and, have someone (one of the moderators?) actually contact Akai Pro's USA office and invite them to participate in the forum, and create a bridge between "us and them".
The reason I think the 3 threads must be moderated, is because I think that for Akai to seriously respond to our input, we need to be sure that anything "sent" to them meets some basic criteria, such as:
For bugs: there must be a clear written explanation as to how to consistently reproduce the problem (software engineers can't fix what the can't reproduce)
For FMRs: there must be a clear written explanation of the requested software behavioral change in context of how it works currently. (Software engineers need a "spec" or "requirements statement of some kind before they can evaluate "how to implement" any request for change.)
For example, I might request as an FMR that when entering a new name for an extracted sample (following a TRIM-menu operation) that the cursor keys work even before I have moved the cursor with the locate keys. (Ever notice that once you move the cursor with the locate keys, only then does the cursor key(s) work [maddening!].
SO, if you've made it this far, and have an opinion, please post it.
And, if you're a moderator and feel that we could provide Akai with meaningful, qualified, feedback, and that someone "here" could contact them to measure their interest in the idea, that'd be great!
Thanks All!
-FlashTheProducer
