PipeWire with rtkit works incredibly stably with wildly short buffer lengths (low latency). Given the short buffer size, there's not much chance for big timing issues to arise (unless there's underruns with dead air, which doesn't seem to be the case).

This was a surprising assertion to hear. Maybe on some OS, doing reliable timing is a problem. But with modern audio pipelines, things feel like they are in an extremely good state.

Actually I am using PipeWire with rtkit on Debian. But somehow it does not solve my midi problems. "Audio pipeline" is not "midi". Nevertheless I am doing all my _audio_ (not midi) work on Debian and I am very happy with it.

If you have hardware synths you are going to have a decent midi and audio interface that this is not a problem. It wasn't even a problem 25 years ago. There is no reason for consumer grade audio to be able to do this because most people will never use it.

I have maybe 20 hardware synths and I do a lot of sequencing. And yes it wasn't a problem 25 years ago, that is exactly why I still use an Atari STe! :-) But today it is a problem. It is just not possible to do complex and tight sequencing today with a normal Win, Mac or Linux computer. Even with my RME PCIe card. Your argument, "it wasn't a problem decades ago, so it cannot today either" is simply not correct.

Midi from a browser suffers from slowdownw due to have javascript is just too slow, non-threaded. There afde ways around it, but those are all workarounds.

Just move put of focus, and you will see how it handles sending clock. I went to a hardware based, external clock signal, and using spp to force syncs between my tools, and use rtmidi+c

From what I understand, midi messages can have timestamps into the future, but that implies buffering on the receiver end. Do most MIDI instruments not support enough buffering to overcome lag? Because in sequencing, the future is pretty-well known.

MIDI 1.0 messages do not have timestamps. (Sys Real Time does, but notes and controllers don't.) Timing is managed by the MIDI sender, and any buffering happens in the interface.

MIDI over MIDI cables is fundamentally not a tight protocol. If you play a four note chord there's a significant time offset between the first and last note, even with running status.

With early MIDI you had a lot of information going down a single cable, so you might have a couple of drum hits, a chord, maybe a bass and lead note all at the same moment.

Cabled MIDI can't handle that. It doesn't have the bandwidth.

Traditional 80s/90s hardware was also slow to respond because the microprocessors were underpowered. So you often had timing slop on both send and receive.

MIDI over USB should be much tighter because the bandwidth is a good few orders of magnitude higher. Receive slop can still be a problem, but much less than it used to be.

MIDI in a DAW sent directly to VSTs should be sample-accurate, but not everyone manages that. You'll often get a pause at the loop point in Ableton, for example.

The faster the CPU the less of problem this is.

If you're rendering to disk instead of playing live it shouldn't be a problem at all.

Bandwidth never was the problem with MIDI, that is actually enough, but your right with _some_ devices in the 80s/90s, that the processor was under-powered for the bandwidth. For example my Roland Alpha Juno 2 from 1986 is somewhat under-powered and not the tightest, but my Casio CZ-5000 also from 1986 is just doing fine! I mean this is almost 40 years ago and there were device that could handle it without problems. The problem with USB though is, that is does buffer in a "non real time safe" way, which leads to unpredictable jitter and interrupts. That means, for MIDI, USB is worse then the original DIN connection.

I am not talking of MIDI in a DAW, without any physical connections, this works just fine.

> MIDI over USB should be much tighter because the bandwidth is a good few orders of magnitude higher.

"should be" != "is". The Atari ST had a ROCK SOLID MIDI clock and direct, bare-metal hardware access that meant the CPU could control the signals directly, with known precise timing. This is simply not possible with modern operating systems and hardware interfaces because of all the abstraction layers, with attendant time indeterminacy, that have been inserted in between. It's physically impossible to match the low latency and jitter of an Atari ST doing MIDI with a modern system.

Yes, they have timestamps. But if you do buffer (or better to say, delay it), you introduce latency, which is even more worse then jitter. The ideal is 0 latency. And another downside with buffering, you would need to manifest the buffer time at all device you trigger to be the same time otherwise you do not stay in sync.

Edit: Actually midi note on events that are being sent to devices do _not_ have a timestamp! Only events that are persisted in a file may have timstamps.

These opinions are not helpful.