Hi guys,
(Note: Important follow-up below the minutes.)
The main points from the meeting were:
- We should write one or more MIDI mapping classes in a reasonable way.
- Garth wants to do some work on the MIDI prefs dialog(s)
- Sane MIDI code should be reusable.
- PortMidi treats input and output as separate devices on every
platform (Win/Mac/Lin). It's done this way because MIDI is a half-
duplex protocol and the underlying platform-specific MIDI APIs only
expose devices this way.
Important follow-up:
I worked on the MIDI mapping classes (MidiMapping, MidiInputMapping,
MidiOutputMapping) for about 2 hours and then realized that there is
just not going to be any way for this code to be reusable without an
insane amount of work ripping out the parts that are coupled to weird
areas of Mixxx. A great example is this piece of code:
void DlgPrefMidiBindings::loadPreset(QString path) {
loadPreset(WWidget::openXMLFile(path, "controller"));
}
I wanted to move the code that loads MIDI mappings (above) into the
MidiInputMapping class. As you can see, it's not in a great spot right
now (the prefs dialog). The $64,000 question is why our generic XML
parsing code sitting inside a static method of WWidget (ie. a GUI
class)? Or rather, why is it being reused like this? I'm not going to
rewrite or even move that openXMLFile() code because I just wanted to
write a MidiMapping class that wasn't coupled in awkward ways. (There
are _many_ other examples like this.) So the problem is that if I were
to borrow code like this for MidiMapping, my new classes wouldn't be
reusable at all, and all of a sudden my morale has hit rock bottom
again. The prospects for the new MIDI code stopped looking good again.
Sean and I just had another chat, and we made some progress on the
fallback plan because the new MIDI code is just going to be impossible
to work with. So here's the deal:
- Feature freeze now (other than the stuff below)
- Disable the LADSPA tab, since we're up to our neck in MIDI.
- We'll keep the old crappy MidiObject-based code.
- Sean just wrote sysex output support for Windows (MidiObjectWin)
- I will write the CoreMidi output support for OS X
(MidiObjectCoreMidi).
- The prefs dialog still needs work, but we think we've thought of a
quick and easy way to fix it:
- Remove the separate device selection dialog.
- Add a new "Device" tab in the bindings dialog before the "MIDI
Input Bindings" tab.
- Inside the "Device" tab, have a single drop-down to select the
MIDI device.
- *** Auto-load a binding on device selection, if it's a device we
have a mapping for. ***
The biggest problem with the MIDI bindings dialog is that it's a bit
difficult to use for new people, so auto-loading the right binding
will mean that most people won't have to tinker with the bindings
interface. This makes things easier for novices, and still gives
advanced users the option to MIDI bind with Tom's interface to their
heart's content.
Garth and others, what do you think about this?
Sean and I think this plan will help us get this release out the door
ASAP, and after that point we can decide whether it's time for Mixxx 2
or what.
Thanks,
Albert
On 3-Jan-09, at 5:49 PM, Sean M. Pappalardo wrote:
> Hello, all.
>
> As the first step to solving the problems Albert ran into, we are
> meeting on IRC (#mixxx on freenode) to discuss the re-design of the
> MIDI
> subsystem code at 6PM/18:00 GMT/UTC on Monday, 05 Jan 2009. That's 1PM
> Eastern, 10AM Pacific. All are welcome to attend and provide input. We
> will send out minutes for review for those unable to attend.
>
> In a nutshell, the goal is to make the subsystem more robust and
> easier
> to maintain by removing all low-level MIDI code from ConfigObject,
> ControlObject & dlgprefmidi*, and replacing MidiObject with new
> MidiDevice and MidiMapping classes. This also allows us to add support
> for multiple MIDI devices. Since Albert has written much of the needed
> new code, we expect that the remaining work involves just
> rearranging &
> organizing existing code.
>
> See you there!
>
> 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
------------------------------------------------------------------------------
_______________________________________________
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
