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
