thestk/rtmidi — pull request #21 by keinstein (2014-03-29 09:38:22+00:00)
Title: Implementation discussion of a reliable port selection API

*Unfinished – don't merge too early*

In order to get into discussion I publish my efforts to get a reliable port selection API for RtMidi.
The main problem that shall be addressed is that the current API does not store port descriptors together with the meta data (port names/port numbers). Thus, both can get out of sync.

The changes start with 33735b5 I'll sort things out later.
The patches include:

• some code reorganization (extract common API into a separate class)
• Add a port descriptor class (With a more flexible port naming interface).
• Add port descriptor API: getPortList, openPort(PortDescriptor &, const std::string&), getPortDescriptor()

I came across the following questions:
• What's the purpose of class RtMidi? Is it used directly?
• RtMidiIn and RtMidiOut serve as API containers. Why do you use virtual inline functions, here? I'd suggest to remove the virtual classifier from the member functions and declare them only in RtMidi if they are used both by RtMidiIn and RtMidiOut. This would render CommonMidiApi useless and I would reintegrate it into MidiApi. Otherwise the inline functions should be marked extern to avoid linker errors.
• There is no function call ot set or get the current API object from RtMidi(In|Out). This and the fact that the implementation classes Midi(In|Out)(Alsa|Jack|WinMM|WinKS|Core|Dummy) are not documented separately suggest that these classes are private to the RtMidi library. Is that right? In this case I'd suggest to remove these classes from RtMidi.h. Otherwise I'd suggest to add two functions to set and get the API object that is used by the RtMidi(In|Out).
• Maybe… probably… I might add a container API that allows to collect several APIs into one common API.
• As I wlil use Cut&Paste to fill in the implementation, some hints would be helpful: What is a good port descriptor for each of the APIs? e.g. for ALSA client and port should be sufficient and are independent from the library call. We don't need to store global data. Are there APIs where port handles are bound to client sessions?