James Coleman
be2e93bcda
- A network port kept a machine it had connected to after the connection was removed, listed it as on the network whenever its host advertised any session, and could not connect to it again: Connect resolved identifiers only among advertised sessions and failed with "no peer named". A machine remembered only for a connection is now dropped once no network port uses it, an untrusted machine is marked present only by a session at its exact address, and Connect resolves remembered machines by identifier or name. - A network port invited the one address it had connected to until it answered, so a session that came back on another port was never reached. The session name advertised at a machine's address is now stored as advertised_as in the configuration, and while the link is down the port connects where that session is advertised and stores the new address. A machine carrying MIDI is never moved. - Each daemon now holds an Ed25519 key in identity.key beside the configuration and publishes mhkey and mhport in every session's TXT record. Two packets on the control port, a challenge and a signed proof, let a network port prove which port of which daemon it is. A machine stored with a proved key and port_id is followed under any name and to another host, with its trust, and a port deleted and made again is not followed. The challenge is sent only to a session that advertises a key, so no other RTP-MIDI implementation receives it. - A machine with no key is followed by name to a new port on its host, and to another host only when it is not trusted, since an advertisement proves nothing and trust is held by host. - An invitation over an IPv6 link-local address was never answered, because the sender's address was kept without its scope. Apple's Network MIDI invites that way and reported that the port did not respond. The address is now kept whole for the control and data ports. - Adds ed25519-dalek and hex. The packet fuzz target reads the new packets. |
||
|---|---|---|
| .. | ||
| cli.md | ||
| configuration.md | ||
| installation.md | ||
| platforms.md | ||
| README.md | ||
Midi Harbor
Midi Harbor manages MIDI connections on macOS, Linux and Windows: virtual ports that applications on the same computer can use, attached MIDI hardware, network ports that reach other computers over RTP-MIDI, and Bluetooth LE MIDI devices. Connections repair themselves. A network connection that drops is reconnected, hardware that is unplugged and plugged back in picks up where it left off, and notes that were sounding when a link went away are released rather than left ringing.
A daemon owns every connection and runs whether or not anything is watching it. The command line and the graphical interface are both clients of it: closing either changes nothing.
- Installation — building, installing, and running the daemon at login.
- Command line — every command, its options, and its exit codes.
- Configuration file — where the setup is kept, and how to write it by hand.
- Platforms — where macOS, Linux and Windows behave differently, and why.
A first setup
midi-harbor service install --start # run the daemon now and at every login
midi-harbor port create "Sequencer Bus" # a port every MIDI application can see
midi-harbor status
To join another computer on the network, create a network port and connect it:
midi-harbor network create "Studio"
midi-harbor network discover # the machines advertising on this network
midi-harbor network connect "Studio" "Stage Mac"
midi-harbor route create "Sequencer Bus" "Studio"
MIDI played into "Sequencer Bus" now reaches "Stage Mac", and keeps reaching it across sleep, network changes, and either machine restarting.