History

James Coleman 5dce49ee43 feat(update): say when the daemon is another build and update it on request - A daemon keeps running the copy it was started from, so after an update the old one ran until the next login and nothing said so; clients compared only the major protocol version. Every build now carries a UUID, the daemon reports it as ServerInfo.build_id under protocol 1.3, and a daemon too old to report one counts as outdated. - The window shows a notice above every page when the daemon it reached is another build, with both versions. Update now registers the copy that was opened as the service and restarts the daemon from it; Not now puts the notice away. Nothing is restarted unless the user asks, so two copies open at once cannot replace each other's daemon in turn. A newer daemon is offered as Use this version, and one the service did not start, or one reached with --socket, gets no button. - service install --start now stops a running daemon before registering and starting, so the daemon started is the program that was asked. Under systemd and Task Scheduler it used to rewrite the registration and leave the old daemon running, since starting a running service does nothing. - service status says when the daemon is another build than the program asked, and --json carries same_build. - The App Store app stops a daemon another build of the app left running and starts its own, instead of attaching to it. - Packaging sets MIDI_HARBOR_BUILD_ID once for everything a run builds, because the App Store app, its helper and each architecture are compiled separately and must agree. Packages of one release share an identifier, so neither replaces the other's daemon.		2026-10-02 11:56:27 -05:00
..
cli.md	feat(update): say when the daemon is another build and update it on request	2026-10-02 11:56:27 -05:00
configuration.md	feat(network): follow a machine's session and forget removed ones	2026-10-02 11:56:20 -05:00
installation.md	feat(update): say when the daemon is another build and update it on request	2026-10-02 11:56:27 -05:00
platforms.md	First commit	2026-09-28 13:59:10 -05:00
README.md	First commit	2026-09-28 13:59:10 -05:00

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.