Issue in MIKMIDIClock::MIKMIDIClockSecondsPerMIDITimeStamp() - Fix inside

[rrc2soft]

Hi everyone,

I found an issue in MIKMIDIClockSecondsPerMIDITimeStamp: in a real iOS environment (iPad mini 4, iOS 10.3), secondsPerMIDITimeStamp was not accurate, and the clock would drift ~0.60s every 60s (in a 120BPM sequence). After some debugging, and thanks to this entry in StackOverflow (https://stackoverflow.com/questions/675626/coreaudio-audiotimestamp-mhosttime-clock-frequency), I found the issue: timeBaseInfoData.numer is a Float32, but the result is a double. So, the division by 1.0e9 would be inaccurate, and the clock would drift. Yet the solution is, as Robert pointed out:

'By casting the first number to double, GCC automatically casts the second number to double as well and the result will also be double'

The fixed code is below:

Float64 MIKMIDIClockSecondsPerMIDITimeStamp()
{
	static Float64 secondsPerMIDITimeStamp;
	static dispatch_once_t onceToken;
	dispatch_once(&onceToken, ^{
		mach_timebase_info_data_t timeBaseInfoData;
		mach_timebase_info(&timeBaseInfoData);
		secondsPerMIDITimeStamp = ((double)timeBaseInfoData.numer / timeBaseInfoData.denom) / 1.0e9;
	});
	return secondsPerMIDITimeStamp;
}

[rrc2soft]

I realize now that probably that (double) conversion should be (Float64) :-)

[armadsen]

Thanks for reporting this. It doesn't show up on x86_64 (ie. macOS and the iOS simulator) where .numer and .denom are both 1, and integer division is fine. On arm64, they're 125, and 3, respectively, so integer division indeed produces an imprecise/incorrect result. I've pushed a fix.