On 1-Jan-09, at 4:40 AM, Tyson Henning wrote: > Oops. > > Well, I know I haven't written the list in a long time, and I'm not > exactly the most reliable chap out there, but I thought I would give > some feedback on this because the subject matter tweaks my interest in > project management. > >> I've spent several days over the break working on rewriting the MIDI >> device I/O code so that it is based on PortMidi and allows for >> multiple MIDI devices to be supported. It took me less than a day to >> do most of that, and the remaining days have been spent bashing my >> head against Mixxx's crumbling internal infrastructure. We've got >> some >> serious problems. >> >> One problem is that in order to handle multiple MIDI devices, the >> concept of a MIDI mapping needs to be well defined. We could either >> have a single mapping contain information about multiple devices, or >> have a separate mapping for each device. In either case, serious work >> on the preferences dialog would need to be done. > > This is the usual result of a design schema being pushed beyond what > it was designed to do. Diminishing returns. > > Feature creep fucks projects. So do hacked designs. > >> Fundamentally, we're stuck because Tue and the original Mixxx >> developers didn't put enough thought into the MIDI code and Mixxx's >> underlying control system. I can't see any sane way to continue >> growing the MIDI code without it introducing dozens of new bugs and >> taking ages to complete. The scope just keeps growing exponentially >> because more and more serious design flaws keep coming to light. >> Instead of someone refactoring and fixing this at Mixxx 0.9, people >> kept patching and hacking crap onto it. When us new developers came >> along, we didn't know the codebase well enough to see these glaring >> design flaws, and since the old developers just up and left without >> any further contact, we had absolutely no guidance at all. > > That sucks. I've been in situations like this, and there is basically > no redeeming feature to being at this point in a project. Nothing is > fun any more. You push one bit, and something way over at the other > side of the codebase springs out of its place and smashes against the > floor. The larger a program gets, the more often this will happen. > Design is a counter to the entropy of codebases. > >> Because of >> the fatal lack of good object-oriented design in Mixxx, I think we've >> pushed the MIDI code, ConfigObjects, and ControlObjects as far as >> they >> can go. I'm effectively canceling the MIDI redesign I was working on. >> >> So how do we get out of this mess? Sean can continue hacking the MIDI >> scripting stuff into our old code, because that should still work and >> will let us support funky new devices. Someone else needs to whip the >> MIDI prefs GUI into shape by allowing only single devices to be >> selected and addressing some usability issues in the bindings dialog. >> We will only be able to support MIDI output on the Windows and Linux, >> unless someone feels like writing MIDI output code for >> midiobjectcoremidi.cpp. >
Up to this point, you've pretty much nailed it. > May I suggest planning a way to get Mixxx's current features just > 'done', locking that in a feature freeze and then... Dare I say it, > redesign it? Is there anything that is particularly desirable or > necessary in pushing the current codebase further other than perhaps > pride and feature creep? I'm not the final word on this, but I'll say that personally I think this is a reasonable thing to do (thanks for suggesting it!). (Also, while I do like my code being put to good use, I have no problems with disposing of any or all of the code that I have written for Mixxx. It's not that it's bad code, but rather that the experience I've gained by working on Mixxx is much more valuable than the code itself.) > What is it that Mixxx doesn't do that makes > it unusable as a DJ application? Are any of the planned features going > to have a payoff bigger than the pain of squishing it into the code? > Well, in response to the first question - The DJing use case is slowly becoming a moving target. Mixxx covers many of the "traditional DJ" use cases, but if you look at how people use Ableton Live, you can see how things are changing. To answer the second question, I don't think so. After having worked on another two other audio applications myself, I think we've endured way too much pain already. Audio development really doesn't have to be this hard. :) > I think that a ground-up redesign would allow for redefinition of > scope, a clean break with the shoddy internal interfaces, in > particular with the MIDI code, and give new challenges. Fresh horizons > you could say. Again, don't take this as written law, but I agree. > > > Or not. Mixxx is a cool application as it is, and largely working, Thanks :) > but I think for the current code to ever really be a desirable > choice over > the competition, new features need to freeze, and work needs to be > done to just consolidate what is there for reliable use. Finish it, in > other words. There is a continual tendency in open-souce projects to > keep moving, keep moving and never finish anything. The result is a > very broad, featureful and innovative program that no-one ever uses > because it's hard to use and buggy. Once again, I agree. We've already been talking about how the ControlObject and ConfigObject frameworks are on the chopping block, but I think the effort involved in replacing those would not be worth the time cost. Even at the end of it, the code we'd have wouldn't be great because the use of ControlObjects has lead to awkward class designs in many parts of Mixxx. (And in our defense, we were just trying to make do with the code.) Finishing Mixxx with the next release sounds appealing to me, and I think a lot of people who've contributed to Mixxx and struggled with our codebase would be in favour of this. (Of course, they'll have to speak for themselves though.) :) > > > So why not a scratch-built Mixxx 2? Or even a different program > entirely? I think that it would make the inclusion of some of the more > advanced planned/in-pipeline features like the timeline and scripting > stuff more central to the design, rather than tacked-on hacks. > I'm in favour of this for after our next release, but we'll all have to have some serious discussions before any decisions are made. > And if it's documented, thoroughly thought out and employs experience > from the current codebase, it may not be such a huge pain for the next > people to pick it up. > > Egh, I'm too cynical, and quite possibly just an asshole, Your words, not mine :) No, but seriously, thank you for suggesting Mixxx 2 or something new. I think you've brought this up at a very good time, and I think the next few months will be interesting. Thanks again, Albert ------------------------------------------------------------------------------ _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
