I've added a signal to MidiObject called devicesChanged().
MidiObjectCoreMidi emits it when it is notified that a midi device has
been added or removed. I wired it to a new slot
DlgPreferencesDlg::rescanMidi() so that as you are looking at the
prefs dialog it keeps up to date with what midi devices are plugged
in. I did this because we've got to be the *only* midi app on the
planet you have to restart to pick up new midi devices.

I'm writing because I don't know have ALSA or OSS or Portmidi or
Windows MIDI at hand; whoever is taking care of those APIs should, at
their leisure, add emit(devicesChanged()) calls at appropriate places.

Issues still open:
-It would be nice if the signals were midiDeviceAdded(...) and
midiDeviceRemoved(...) but I don't think we have a very good way of
identifying each midi device: a midi device is essentially identified
by it's MidiObject+a string. It might be a worthwhile refactoring to
each MidiObject into a MidiDevice, only pointed (and then there's the
flexibilty to use multiple MIDI APIs -- not that that's a good thing)
that we could then refer to by pointer.
-Sometimes I can get the prefs dialog to display 2 copies of my
device. It's definitely a bug in the GUI code somewhere (I have the
model print out its device list and it's never more than 1), but I
haven't been able to find it

-Nick

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel

Reply via email to