2010/9/9 Albert Santoni <[email protected]>: > 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. >
The scripting capability is indeed one of the things that make Mixxx really attractive, apart from being one of the few open source alternatives. Most users as you say will test Mixxx with a mapping provided with the installer, if it doesn't work well it's probably removed right away. Some controllers have better mappings floating around on the forum, so I guess one thing to improve the situation quickly would be to locate these and provide them with the installation package. The challenge there is of cause how to identify which mapping is working better then the provided. I tried to get my mapping into Mixxx by posting it on the forum, and send a mail to this list. I did not get much response for that, the old 1.7 mapping is still provided. > 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 One could ask manufacturers to provide hardware though. I guess it would have better effect if "the team" behind Mixxx asked for controllers to be provided for better support, rather than me as a random developer asking if they want to send me a controller. > - 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) I think there might be means of improving the situation with help from the community. I've looked at a few mappings posted on the forum to see if I can help out. And some seem to be fairly good. A few things that could improve the situation is: -Improve the documentation. For example the list of controls still have a lot of question marks. Also it's not easy to interpret what units are used for all controls. -Provide guidelines for what to do if you want to provide a mapping. For example : Put a manual on the wiki to provide info on how to use Mixxx with this controller, along with a download link and maybe a link to video of how to use it. -Improve the control objects for greater flexibility for script writers. On thing is to unify units. For example make it possible to check if a deck is at the cue-point by comparing the current play position, now given as a value 0..1, to the cue position, now given in absolute samples. Another example for units is if I want to set an auto-loop of 8 beats. How do I do that without the track sample rate? -Provide generic building blocks for scripts, that speed up the process of writing. -Provide examples of what not to do, and why. An example is busy waiting that can be found in various scripts. -Make it more logical for how to update mappings. Right now it's possible to update the script but have the old cached xml. I vote for either caching of the script or to auto-update from the xml here. I just found out how to register for the wiki. =) I will try to make some effort to some of these points, at least for my control. > - 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. > I agree that it would be good to have some way to indicate how well a controller works with Mixxx. Now it looks like a lot of barely supported controllers ,with nothing more than recorded midi mappings, are usable. > >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 personally don't like the idea of putting to much attention to such a limited amount of controllers. The good thing about Mixxx is that it can be well integrated with most controllers, and I think the main focus in the controller area should be to improve this ability and to make it easier to integrate new controllers. However, I think that cooperation with hardware vendors should be encouraged. And that their hardware should get more attention if they provide hardware, documentation, support, money etc. Perhaps one can agree to link each others web sites, get vendors to distribute Mixxx, and maybe get them to certify that Mixxx is well integrated with their controllers? Has there been any efforts made to start cooperation with vendors? Why not try to initiate contact with a few? In that case who can contact a vendor and under what terms? > 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 > ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
