On Thu, 9 Sep 2010 11:22:42 -0700 Albert Santoni <[email protected]> wrote: > > I don't want to see users going to our website, seeing that their > controller is "supported", downloading Mixxx, and then finding out > their jog wheels or button XYZ doesn't work. We're turning off a lot > of non-technical users like that, and it's giving people a bad first > impression of an otherwise good piece of software.
I totally agree. I had the same feeling first time I tested my BCD 3000. Half of the stuff working and the rest was left up to me. I was also disapointed when I switched from 1.7 to 1.8 and found out that the jog broke. The hardware interface adds some kind of "feeling" to the software, it's like having a broken keyboard, you won't want to use your pc. It has to work right out of the box. > There are different ways we can work together to improve our MIDI > support going forward, and I'd like to hear your ideas. To get the > conversation started, here are some of my ideas: > > I think a good starting point is to differentiate between "Officially > Supported" controllers and "Community Supported" controllers. This > will reduce our quality assurance workload and allow us to focus on > providing a great user experience for a small number of controllers. > We can also turn the problem on its head and think about this from the > perspective of the controller manufacturers. Companies want their > controllers to work well with Mixxx because we sell their hardware. We > turn a lot of "new to DJing" people into "DJs with hardware", so there > is tangible value in ensuring Mixxx properly supports a controller. > > >From this perspective, I think there's also an interesting > opportunity. If Mixxx were to only "officially" support maybe 4 > controllers, we could: > A) Ask hardware vendors to pay for their controllers to be supported. > I think being able to dedicate guaranteed resources to MIDI QA (eg. > buying Sean's time) each release would allow us to do the job right. I > don't think this is a ridiculous idea because people will buy the > controllers that are officially supported in Mixxx. Again, we're > providing sales for these hardware companies. Most of the time I see two possible non exclusive way for a company to react : - provide hardware and support to developers - have someone from their company do the mappings/scripts and send it upstream > B) Make our MIDI QA workload manageable. We'll never be able to > support a dozen controllers without being able to throw a > proportionate amount of time at them. If we price it right, then our > resources should scale with the number of controllers we officially > support, giving us the option to grow. See my second comment for point C. But I think that once the low level interface will have clearly documented expectations, it will be a lot more easier to actually have all the controllers behave the way you want and will require a lot less maintenance. > C) Create a proper MIDI QA test suite that includes what the expected > functionality is for every knob and button on a controller. This > should be agreed upon with the manufacturer because as a hardware > company, I want our controller to work the way we intended. Two comments regarding point C. First the expected behavior of each knob/slider/button/etc should be documented on a wiki (preferably with pictures etc). This will allow the users to choose the controller that will suit their need before buying it. Second, on a more low-level side, the effect of a specific value for each control must be documented and QA'ed. This is trivial for buttons. However for a control like jog, there is currently no documentation on what value to feed it (max and min), how often (in ms) and what will be the expected behavior wrt the obtained rate. For this specific example, the wiki says the values are -3 to 3 but you can actually feed it whatever you like. It needs to be enforced as well. > D) Create a win-win-win situation, where Mixxx users benefit from > better supported controllers, hardware companies benefit through sales > from being one of these few officially supported controllers, and we > benefit by creating a better piece of software. And better dj's :) My 2 cents, Guy ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
