Hello. I'd like to offer my inexperienced two cents. Feel free to completely disregard. ;)
Albert Santoni wrote: > 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, Is any of that usable? At least from the standpoint of easier cross-platform MIDI output? > 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. Let's decide on this now. My vote is a separate mapping for each device type. I.e. if you have two of the same model of device, you can use the same mapping XML file. Mixxx will assign the MIDI channel value on-the-fly (after asking the user which channels the devices are on unless that can be auto-detected,) so the XML will have no <midichan> tags. In the short term, having a separate device file for each physical device (where you change all the <midichan> tags yourself) should be quicker to get working and release. > 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. Without having seen the PortMidi code, can one create, in a reasonably short amount of time, a sort of "virtual device" wrapper class that interfaces between Mixxx and PortMIDI, doing the device aggregation itself? It would essentially allow Mixxx to talk to a single VirtualMidiDevice object (per physical device) which then is the only thing that talks to the multiple PortMidi objects for the time being. Yes it's a hack, but it would allow us to move to PortMIDI sooner, thereby obtaining the benefit of cross-platform MIDI output support, which scripting requires. Once multiple device support is ready, we remove the VirtualMidiDevice class and use PortMidi objects directly. (So clearly mark everywhere the wrapper is used for easier future correction.) > 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. I venture to say that the hundred new bugs will be worth fixing in the long run just to get away from the duct tape and chicken wire. Without having to change the rest of the functionality of the ConfigObject system, it doesn't seem _too_ difficult in my mind to re-implement MIDI mappings outside of it. I can take a crack at this, but we need to have a hard & fast design first. (See below.) > 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. Understandable. Thank you for the work you have done and for enumerating what needs fixing. > 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 By old code, do you mean current trunk, or pre-Tom? > Attached is all the code I've written that I'm about to throw in the > garbage. Can you upload the ZIP file (and the patch) somewhere? Your school's mail server blocked it. Moving forward, I agree with Yorick's suggestion: declare a feature freeze for the next release, and we'll simply work on fixing bugs. Unless we do this already, perhaps moving to Mozilla's method might be helpful, where they branch for each release. No more releases from trunk directly. So for 1.6.5, I feel that MIDI scripting is nearly ready for public consumption, as I think I have the Automatic Reaction bit sorted out. (A bit more testing to do.) After that, there is some cleanup work to do regarding loading script files which won't take long to fix (adding a couple tags to the XML to specify which file(s) to load.) So I suggest including MIDI scripting in the feature freeze list for the next release. (Personal pride plays little part in this: we need this feature out there ASAP to be ahead of everyone else and offer users currently frustrated with the limitations of commercial packages a near-ideal solution. Our window of being first with this is limited.) As for reimplementing the MIDI back-end, I think we all agree it has to be done, so let's start designing now. What should it look like? The UML Albert did looked good to me to start. Please reply with your thoughts. I'm interested in feedback, good and bad. Sincerely, Sean M. Pappalardo "D.J. Pegasus" (Pegasus_RPG) <<--------------------------------------------------------------------------------->> This E-Mail message has been scanned for viruses and cleared by >>SmartMail<< from Smarter Technology, Inc. <<--------------------------------------------------------------------------------->> ------------------------------------------------------------------------------ _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
