Page 1 of 1

Hatari MIDI for OSX and Windows

Posted: Mon Sep 25, 2017 4:20 pm
by jariseon
I've implemented MIDI support for OSX and Windows Hatari. Eero has been most helpful and is reviewing the patch.

MIDI support has been tested in OSX and it seems to work ok, including sysex. However, there's a weird periodic 12 ms jitter in Hatari MIDI output, at least in OSX. It is present in current Mercurial tip midi.c (i.e., even without my code, which I first suspected to be the reason). The attached graphs illustrate the issue. Vertical axis is latency time in msecs, and horizontal axis is time in midi packets. Positive vertical value indicates that a noteOn command is generated late, and negative that it is generated early. The expected ideal curve would be a flat horizontal line at 0.

I don't know anything about timing in the emulator internals. Can someone please jump in and figure out what is going on? I can provide the related code used to make the measurements. Would be great to get MIDI timing tight as there are really good sequencers available for ST. And Hatari can run them all. It's awesome.


Re: Hatari MIDI for OSX and Windows

Posted: Mon Oct 02, 2017 7:11 am
by lokki
i did a lot of tests with hatari on Linux and sysex sent to a hardware synth and i get crashes regularily on the synth if i send big sysex packages. so it might well be the same jitter. anybody else sending big amount of sysex on linux?

Re: Hatari MIDI for OSX and Windows

Posted: Mon Oct 02, 2017 8:17 am
by npomarede
IIRC when I improved Hatari MIDI support at the ACIA level, I noticed some MIDI programs like cubase or others had some code to compensate for a possible clock drift, adjusting their rate to keep timings in a desired window.
Isn't that what we are seeing ? Does it have any negative impact on the MIDI device connected on the other side (lag, missing notes ?)
Depending on how the MFP timers are used by Cubase, it's also possible they chose a frequency that is not an exact multiple of the expected freq, so you need to have this adjustement steps, made by Cubase midi logic.
How did you measure this drift ? By measuring delay between each byte output on /dev/midi (or equivalent) ? Is so maybe cubase needs a real device on the other side to ack each byte and compute some kind of clock where jitter would be lower.

It could also be a bug in Hatari :) But as some midi programs ('M' and 'Notator) had big issues at some points (loosing notes, getting stuck, ...), I really had the feeling accuracy was now correct.


Re: Hatari MIDI for OSX and Windows

Posted: Mon Oct 02, 2017 10:02 pm
by jariseon
Hi and thanks for the comments.

On OSX MIDI works great except for the jitter. No stuck notes and sysex at least up to 63kB works well. No bytes dropped. Hope the PortMidi version will work also in Linux to help with large sysex dumps.

I tested with Cubase 2.01, Cubase 3.01 and MasterTracks Pro 3.6, using latest tip and 1.04 ROMs, OSX Sierra as host. Thought first that cracked versions do some funny business behind the scenes, but the jitter was also produced in MTPro (which is legit). However, I noticed that the tempos were slightly off from the set 120 bpm (119.88 bpm in both Cubases and 120.47 in MTPro). I try to find Notator and see how it performs.

Maybe those tempo offsets are related to MFP timer freqs? I can't exactly remember how tight Cubase and MTPro were on hardware ST. IIRC, ST was pretty tight though and jitter was around 1 ms. But my memory might fail on this as periodic jitter indeed suggests drift compensation.

I used the code below to capture the jitter (in midi.c, Midi_Data_WriteByte(), line 289 onwards). Did not have a device connected during the capture. But when I recorded Hatari MIDI out in Ableton, Bitwig and in Snoize's excellent Midi Monitor at OSX side, the jitter was there as well in a similar periodic form. I used a simple 16th note drum pattern in tests, single pitch at 120 bpm. Maybe I'm just doing something stupid or there's something weird in my setup.

Code: Select all

#include <CoreAudio/HostTime.h>
static double onsetBuff[150];
static int onsetCount = 0;

if (onsetCount == 150) {
   for (int i=0; i<150; i++)
else if (onsetCount < 150 && nTxDataByte == 0x90) {
   Uint64 t = AudioGetCurrentHostTime();
   double timestamp = t / AudioGetHostClockFrequency();
   onsetBuff[onsetCount] = timestamp;

The code collects noteon event onset times into onsetBuff[] array. Once it has captured 150 of them, it prints them out. I suspected that printf might influence the results, so I collected the events into the array first. I then copy-pasted the printed timestamps into Excel, subtracted the values from theoretical onset times (computed from an ideal 16th note pattern and taking into account the tempo offset), and plotted the graph.

Would be great if someone can capture the onset timestamps and post them here. I can then crunch the numbers in Excel.

Thanks again,

Re: Hatari MIDI for OSX and Windows

Posted: Tue Oct 03, 2017 8:19 am
by npomarede
thanks for the details and your patch for Hatari. As you say, it would be interesting if someone could check behaviour on real HW, because it's quite possible jitter was already present due to some MFP limitations. Although I'm not sure people used to push 63 kB of data on real ST ? Or maybe this is a limitation of Cubase.
There could be some bugs in MIDI emulation, but I'd like to be sure it worked better on real HW before looking into this.


Re: Hatari MIDI for OSX and Windows

Posted: Wed Oct 11, 2017 11:59 pm
by cb170
Holy crap, MIDI in Hatari *finally* works in OSX - huzzah!

Thanks for everyone for implementing this - made me really happy!

I just had Snoize Sysex librarian transmitting sysex from OSX into my old "Dump It!" sysex program running in Hatari, and vice versa - it works great!