MIDI - is not dealing with explicit sourcePortIndex and name

[sensestage]

(
~descInput = (
    idInfo: ( name: "SuperCollider", sourcePortIndex: 0 ),
    protocol: \midi,
        description: (
        'key': (
            type: 'pianoKey',
            midiMsgType: \noteOn,
            midiChan: 0,
            midiNum: 64, // note number
            spec: \midiVel,
            ioType: \in
        )
    )
)
)


(
~descInput = (
    // idInfo: ( linux: "SuperCollider", osx: "IAC-bus" ), // Linux: this may need to be different on OSX
    idInfo: "SuperCollider",
    protocol: \midi,
        description: (
        'key': (
            type: 'pianoKey',
            midiMsgType: \noteOn,
            midiChan: 0,
            midiNum: 64, // note number
            spec: \midiVel,
            ioType: \in
        )
    )
)
);

[adcxyz]

Actually this is even a bit trickier:

1. single device, single in, single out port
   • this is the most common case, and works already
2. multiple devices of same product, each with single in, single out port :
   • which in belongs to which out?
   • if we do access by sourceIndex, destIndex, are these guaranteed to be in the same order?
   • The MKtlDesc is the same object now for all instances of the same product,
     so the the which one to use must be independent of the MKtlDesc.
3. Single device, multiple in and out ports
   • We should know on which ports to listen for which elements
     (matching to all uids in the MIDIFunc also works, assuming there is no difference
     in meaning of e.g. noteOn 60 64 0 from srcID1 to noteOn noteOn 60 64 0 from srcID2)
   • we must know on which ports to send back which values
   • and where to send sysex messages etc to.
4. Multiple devices of the same product, each with multiple in and out ports
   • how do we know which ones belong to the same physical device,
     so we can group them together in one MKtl (by subMKtls or otherwise)?

[sensestage]

Our latest agreement in the Modality meeting was that for devices with more than one source or destination, we would have several description files, and combine them in one MKtl.

[LFSaw]

yepp, done with commit 97ed9b5, merging to be done later #234