Hi guys,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.
The second problem is that in order for PortMidi to work nicely on OS X, we _have_ to support multiple MIDI devices. CoreMidi treats input and output as separate devices, so in order to have something full- duplex, we need to support multiple MIDI devices (and therefore sort out the MIDI mapping problem). I tried to make our code aggregate half- duplex devices into single full-duplex ones, but PortMidi doesn't expose any information that tells you that two "devices" are really a single physical device in a cross-platform way. That means we can't aggregate devices reliably.
A third problem is that the MIDI prefs dialog still needs a lot of work. It currently allows you to select multiple MIDI devices, which shouldn't be the case as we don't support that. It also lets you enable/disable receive and send on MIDI devices, which I think is total overkill and will confuse the hell out of our users. You should just check the MIDI device you want to use and transmit/receive would be automatically taken care of by the underlying code. (ie. If it is an input device, read from it, etc.)
A fourth problem is that the MIDI mapping system uses our ridiculously terrible ConfigObject system. Why are our MIDI mappings using the same data structure as our settings saving code? Nobody even really understands how it works, so I can't even conceive of replacing it without having a hundred new bugs pop up.
A fifth problem is that I'm totally out of energy for this MIDI project. I definitely wasn't planning on rewriting the MIDI device I/O code... ever.
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. 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.
Attached is all the code I've written that I'm about to throw in the garbage. It works for single devices only, because everything else was written to support one device (midi mapping code, GUI, etc.) and I'm not an infinite well of energy.
Albert -- A file objectoriented_midi_code_newclasses.zip attached to this message has been deleted by the University of Western Ontario's mail server because its type has been identified as a possible security risk to you. For more information, please visit http://www.uwo.ca/its/email/blockedfiles.html
objectoriented_midi_device_code.patch
Description: Binary data
------------------------------------------------------------------------------
_______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
