Hello, My views on this have always been that we should try to only implement features which measurably improve the experience of using Mixxx for a significant number of people or whatever equivalent phrase I wrote in the wiki page on Mixxx development guidelines.
In this specific matter I think very few people are ever going to create a full MIDI mapping themselves, in the first instance we should always encourage them to look on our website/forums. Producing a new one will almost invariably involve writing script, which is a lower bar than we used to have when they had to write C++ but still requires a lot of involvement. I think if you're at the point where you're willing to learn a scripting language and an API in order to make your lights work, then asking them to edit a text file is not that big a deal. If you don't want to edit a text file, you probably don't want to or know enough to learn about the API anyway. I mean ideally we'd have a super IDE inside Mixxx where you write modules and link them to midi events and ponies but we don't need that to satisfy the vast majority of people and that time could be better spent on other things (like the library...). The point of this midi learning code is to satisfy the people who are willing to fiddle a little to get their controller to work but not a lot. If you were willing to fiddle a lot then you would be editing your XML file already. I think that means I agree with Albert? Adam 2009/3/11 Albert Santoni <[email protected]>: > > On 11-Mar-09, at 8:02 AM, Garth Dahlstrom wrote: > >> "vast, vast majority of our users." ... mmm stats... mmm donuts.... >> >> You could make the case that all this device configuration stuff >> will never be used by the majority of our users, being that the >> majority of the thousands and thousands of people who download Mixxx >> will never have anything beyond a mouse, some kind of 2 channel >> sound card and an XP PC... But then if you think exclusively like >> that you'll end up tossing out shoutcasting, recording, vinyl >> control, midi learning, flac & ogg, jackd support and you'll end up >> with a slightly spiffier then usual two deck MP3 player with a cross >> fader on it that only runs on Windows. > > I think that's an unfair over-generalization. We had many people say > specifically that they wanted some form of MIDI learning, shoutcast > broadcasting, FLAC/OGG, etc. Nobody's ever said they wanted Mixxx to > help them setup outputs for their MIDI controller. > >> >> I don't mean to come across as a troll, but I would like to see us >> drop this 'majority of users' decision making rational bs and just >> try to build stuff that appeals to a wide+deverse audience of people >> who like to DJ music and which approaches a level of usability that >> people can figure it out without digging around on google. > > Calling our tried-and-true development strategy "bs" perhaps wasn't > the most tactful way getting your point across, but I'll reply to this > anyways. The MIDI output table has nothing to do with targeting a > wider audience, and it has everything to do with refining the scope of > what I'm going to finish for 1.6.2 before it gets released. > At the higher level where we make design decisions about where to > drive the project, we do try to serve as many DJs as possible, but > this is far from BS goal. This goal already encompasses a long-term > strategy of appealing to a wider and more diverse userbase. On top of > that, spending our limited resources on features that appeal to very > small subsets of our users is a recipe for disaster. Think about the > old mouse-control stuff, the joystick stuff, the awkward Powermate > code, the hacky TCP server thing, all that crap from the old > development team - It was all feature creep from people trying to make > Mixxx serve them coffee. Focusing development on features that will > benefit the most users is the project's best line of defense against > feature creep. (And this is all especially true bearing in mind that > we still have major usability problems like our library that affect > most of our users. That stuff needs attention way more than making it > so that 10 people can make their MIDI controllers lights' flash > without touching a text editor.) > >> >> I'm biased about this stuff having been involved in the previous >> incarnation. > > Are you sure you're in a good position to comment on the current > design then? > >> And I don't like people having people muck with config files, I've >> done enough of that and seen users mess stuff up too many times... >> Were I'd like to see the interface get too is: >> Input: >> - Wizard >> - Table >> - When you have a script binding in the table, there's a little >> button on the left (like the X overlay on library search), click on >> it and it opens the Javascript file to the bound function for you to >> see/edit (maybe reuse script studio dialog), with a JS syntax check >> when you save/close. > > We already have the wizard and the input mapping table almost > complete. I'd like to see some easy inline script editing too, and > maybe I could have written that if I hadn't wasted my time on the > output mapping table. (I think it would have been way more useful too.) > >> >> Output >> - Wizard (yup, another wizard) >> - Table >> >> I think the wizards help people who are unfamiliar with the >> interface by demonstrating what is going on, and after a few runs >> through the wizards people will start to "get" how the tables are >> set-up. >> >> I was watching a video blog that Math` posted in IRC on TouchOSC and >> I saw the mapping for OSC to MIDI and it looked like a giant circuit >> board blueprint. I guess if you are used to that, it might be >> alright, but I was looking at it going, how would I have ever built >> such a blueprint knowing nothing about the tech + apis... I think >> our interface is a good level of complexity without being insane >> considering. > > How many controllers have you looked at their lights/output specs for? > There's absolutely no consistency between any of the controllers, and > the rising complexity of our XML to deal with that is the proof. > > There's absolutely no way we can make an output wizard, lest a useful > output mapping table because there's no standard for any of this MIDI > lights controlling stuff, and it's VERY very easy for a new controller > to come along and just not work with the output mapping design. (For > example, Math`'s Denon controller needs some funky output cases that > we can't handle, even after all of our work.) Basically, this is an > impossible task because we're being asked to design a piece of code to > solve a problem that's hugely underdetermined - We have no idea how > crazy the output mapping system will have to be in order to handle a > controller that comes out tomorrow. The only way to combat this is > with scripting, and that, we already have! > > Albert > > >> On Wed, Mar 11, 2009 at 3:10 AM, Albert Santoni <[email protected]> >> wrote: >> Hi guys, >> >> I'm sitting in bed hacking and I just had this giant epiphany - The >> MIDI output mapping table in the prefs is going to be so complicated >> that it's going to be impossible to use without looking at our >> documentation. And experience has shown, the 1% of the people that >> read documentation can probably write XML. And we're talking about the >> 0.001% of our users that will actually want to set up MIDI outputs by >> hand. >> >> I wish I had realized this about a month ago, before I went ahead and >> wrote it. I've added a piece of complex code with many function >> points, and it's going to do absolutely nothing for the vast, vast >> majority of our users. >> >> Is there a single good reason to keep this? >> >> Albert >> >> P.S. We've put a huge dent in our 1.6.2 TODO list, and I'm going >> through it in my head figuring out exactly which things we need to >> focus on in order to finish the release. I'll send an update to the >> list when we enter our final push... >> >> ------------------------------------------------------------------------------ >> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) >> are >> powering Web 2.0 with engaging, cross-platform capabilities. Quickly >> and >> easily build your RIAs with Flex Builder, the Eclipse(TM)based >> development >> software that enables intelligent coding and step-through debugging. >> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >> _______________________________________________ >> Mixxx-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/mixxx-devel >> >> ------------------------------------------------------------------------------ >> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) >> are >> powering Web 2.0 with engaging, cross-platform capabilities. Quickly >> and >> easily build your RIAs with Flex Builder, the Eclipse(TM)based >> development >> software that enables intelligent coding and step-through debugging. >> Download the free 60 day trial. >> http://p.sf.net/sfu/www-adobe-com_______________________________________________ >> Mixxx-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/mixxx-devel > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Mixxx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
