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. 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? 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? 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. Or not. Mixxx is a cool application as it is, and largely working, 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. 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. 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, but in my humble opinion a new project is definitely worth thinking about. Happy new years! I hope everyone drank a lot of Hobgoblin. ~Yorick ------------------------------------------------------------------------------ _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
