MIDI 2.0 timing test tool and spying on ports in use

[Vaynerix]

Hi Sema,

I'm glad to see your work on the MIDI 2.0 stuff. Looking forward to try to implement it on something like Ableton Push 3 (Standalone on Linux).

I'm wondering if you have any insights on what the most accurate tool or device is to measure MIDI 2.0 Timing.
Node.js supports high resolution time (hrtime). I assume you're using this or something similar for the timestamps.
And what speed limitations (if any) are known when using JZZ in Node compared to other possible MIDI Drivers? (most of them built on RTP MIDI / Bonjour / ALSA and in Ableton's case it's running through a layer of Python)

MIDI 2.0 has the Jitter Reduction Clock, which could log the differences between the incoming timestamp, local time and outgoing corrected time offset. And I suppose the logs (or recordings) will look different depending on the platform and how Node is running (natively or inside an app like Max/MSP).
I'm mainly curious how we can test that the Jitter Reduction works as intended on different machines running various CPU clock speeds. And if Node is faster or slower compared to solutions in other programming languages. (I realize there isn't anything publicly available to compare with yet)

And lastly: Most MIDI Drivers prevent connecting to ports that are already in use. MIDI Monitor on MacOS can spy on those ports. Can JZZ spy on ports that are already connected to a DAW? For example using Ableton Push, the MIDI from the controller is remapped by a python script. Pad 1 sends Note 36 from the controller, but in Live it's remapped to whatever note it corresponds to according to the chosen Musical Scale and Octave offset. And that note may be mapped several times across the 64 pads depending on Scale settings.
The only way to determine which pad was played is with the Live API observers, but the result arrives so slowly that it becomes useless.

I want to keep the functionality of Push being connected to Live, but I also want the raw MIDI from the controller. Preferably with comparable or even lower latency than the MIDI coming from the Python script.

Thanks for all your hard work!

[jazz-soft]

Hi! Thank you for the interesting questions!

Since JZZ is a JavaScript library and JavaScript has never been too precise with the timing, you cannot expect a scientific precision from it.
On the other hand, as long as the imprecision is not audible by a human ear, we should not worry about it.

I am not aware of any specific tools for testing the Jitter Reduction.
You may want to ask this question to the experts at https://www.midi.org/forum

I don't think it is possible to spy on the MIDI channels that are already open.
However, you can try using https://github.com/jazz-soft/midi-test (Mac and Linux) to create MIDI ports that you can listen and redirect to the other ports.

[Vaynerix]

Thanks for the reply.
I suppose I'm less interested in having near audio rate MIDI and more interested in how the various software implementations stack up against each other. And you're right, it's probably a good question for the folks at the MIDI org. I just figured with all your various tools and experiences across languages, perhaps you already knew of or made a test to measure jitter.
And yeah, you're not going to feel the difference in playing since the differences are probably shorter than interface/plugin/DAW latency.

The thing I really want to play with is recording and playback of high-res automation and the new MPE features.
Apart from Logic, there isn't much that MIDI 2.0 can talk to yet. At least not for us.
I know my way around Live and Max/MSP, less so in Node and the MIDI 2.0 code.
The thing I hope to copy/paste together is a Node patch that runs JZZ in Max/MSP that provides an inlet and outlet for raw MIDI 2.0 events. From there, synths, players, recorders, generators, etc... can be made to test the new features.

A controller like Ableton Push has a Live Port that automatically connects to Live. This means the MIDI port can't be accessed by other apps. And you can't route it through a virtual MIDI port because Live will always find and connect to the real port.
MIDI Monitor is the only app I know that can see the MIDI from the controller and what Live sends back to the controller while Live is running. They found some clever workaround or some undocumented thing.
If it were possible to do this with JZZ, it would theoretically work on Push 3 that runs on Linux and can run Node runtime with a Max for Live device. Making Push 3 a standalone MIDI 2.0 controller that can be extended with Node, MFL or both.

Is this double MIDI port usage issue something that should normally be addressed with MIDI 2.0 connections according to the protocol? Maybe we're waiting for an OS level MIDI driver update.