Hi guys, As Mixxx has grown, we've started to support many more controllers. Our MIDI scripting engine allows us to create advanced logic for controllers easily, and has let us do cool stuff no other DJ software can do. Our support for the SCS.3d is a great example of how we can work together with manufacturers and use our scripting engine to provide tight integration for our users. On the other hand, many of our other mappings are in disrepair, and it's time to do something about this.
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. So how do we solve this? First, some things we _can't_ do: - Make one guy in charge of supporting 30 controllers - Purchase 30 controllers and distribute them to our team, dividing up the work - Make a controller work perfectly with Mixxx 1.9, and assume it will still be working in 1.10 - Rely on our community to produce production-level mappings (one person's idea of polished is not the same as another person's) - Test community provided mappings to ensure they work (we don't have the hardware) Supporting a MIDI controller is not a one-off activity like we've been treating it in the past. Instead, our experience has shown that it's a process that must be followed for each release. It's time consuming, but if we really want controllers to work the way they're intended, it's necessary. 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. 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. 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. 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. I'd like to hear what everyone thinks. Remember that whatever direction we decide to go, it definitely won't be for 1.8 and probably not for 1.9 either. Thanks, Albert ------------------------------------------------------------------------------ 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
