NOTES


# TODO

[x] case insensitive client and port name matches

## future

[] periodically check clients and ports for name and capability changes
    (since, due to kernel bugs, the change events are never sent), and if there
    are changes, remove and re-add the relevant ports
    N.B.: Not clear this is really needed, since we don't see any applications
    that really change port names or capabilities after being created. See the
    code in MidiMinder::handleSeqEvent for details about client name changes.

[] figure out how to fsync in Files::writeFile()

[] ? on soft reset, we could just scan activeConnections and only disconnect
    those that the rules wouldn't put back; and then, when adding back the
    ports, be careful to not try to reconnect connections that remainded
    (or just ignore the ALSA Seq connection error) - this would ensure no
    disruption of connections when switching profiles where a connection is
    in both the old and new profile. Really may not be worth the effort!

[] make connection-logic-test something that could be used during packaging
    - needs to not write files, nor use ALSA

[-] optimize saving observedRules
    - no longer really needed, as never saved more than once per event

[] ? some way to be graceful about aseqdump - we shouldn't be saving
    those connections as observed rules

[] ? unicode detection in Term

[] ? future possible options for connect/disconnect
    --force, --interactive, --dry-run

[] ? in list command and view command, group ports by type??




# DAW NOTES

PureData
    - When changing number of MIDI ports, deletes them all
      then re-adds them. This works for us.
    - OMG - it sets the name of the client AFTER it creates the ports

Renoise
    - Has separate clients for In and Out!
    - Has non-exported ports first, so user ports don't start from zero
    - Adds and removes ports, at times willy-nilly. If you connect a port
      to a device in the app, it deletes its port, recreates it named with
      the name of the other port, and then connects them.  This seems okay
      with midiminder
    - ? Perhaps we want a "ignore client" list - since Renoise does a fine
      job of managing MIDI ports on it's own.
    - Interestingly: no output ports other than sync!!

Reaper
    - Normally talks to raw MIDI devices
    - Has one "virtual" in and one "virtual" out port, each uses its own
      ALSA client (!), and the clients are named "Client-128" and "Client-129",
      the ports are named "Virtual RawMIDI" no matter what they are renamed in
      the UI.

LMMS
    - Lets users pick other ALSA ports as MIDI in/out for specific tracks
    - Will create a port and connect it for each such assignment
    - Doesn't seem to notice when connections are changed outside of it
    -

Ardour
    - Creates a ton of clients: A pair for each other ALSA port, each client
      has one port in or out. These are connected to each of the other
      ports. BUT, none of the Ardour ports are marked subs - so no idea how
      these connections are made.
    [] caused amidiminder to generate ALSA Seq error -2 in get client info
    [] need to make sure these ports are completely and correctly ignored

bitwig - only x86-64 available
