Noob: Odd MIDI latency issues in spite of latency = 0.0

wolfgangschaltung · December 30, 2021, 4:56pm

I am using a MIDIFighter Twister controller with encoders and LED rings around its encoders.
I use a MIDIdef to call a MIDIOut to control which LEDs should be lit when turning an encoder. After starting the SC app (or after Reboot Interpreter), running the following code and turning the first encoder results in a significant lag (> 1 sec) between turning the encoder and seeing the LEDs react. IAC is active. It is not necessary for the scsynth to run.

(
MIDIClient.init;
MIDIIn.connectAll;

~testvalue = 64;
~mf_out = MIDIOut.newByName("Midi Fighter Twister", "Midi Fighter Twister");
~mf_out.latency = 0.0;
~mf_out.control( 0, 0, ~testvalue ); // sets default value of LED ring
~mf_in_srcID = MIDIIn.findPort("Midi Fighter Twister", "Midi Fighter Twister").uid;

MIDIdef.cc(
	\tester, {
		arg val, num, chan, src;
		~testvalue = (~testvalue + val - 64).clip(0, 127);
		~mf_out.control( 0 , 0, ~testvalue );
		~testvalue.postln
	},
	ccNum: 0,
	chan: 0,
	srcID: ~mf_in_srcID,
)
)

One of the following will fix this latency:

After executing the code above, run just the lines
MIDIClient.init; and
MIDIIn.connectAll;
again. Now the latency is gone until I restart the SC app or reboot the interpreter.
Have AMS, or MIDI Monitor, or GarageBand, or Logic open before starting SC. Once I ran the code above, I can quit the other app and still enjoy zero latency – until I restart the SC app or reboot the interpreter.
~~Disable IAC in AMS, in which case the latency is gone for good, but it also means I can no longer use IAC.~~

Please, what is causing this? Is this expected? Are there any other way to prevent this behavior? Thanks much in advance for any help!

P.S. SC version is 3.12.1, restarting the computer (MacBook Pro 2014 with 10.14.6) did not help.

P.P.S. The code above is quite useless on its own, but it allows to reproduce this issue, the code I am actually using does a bit more.

wolfgangschaltung · December 30, 2021, 9:27pm

Update: Sorry, I was misled, disabling IAC in AMS does not make any difference.

The only remedy seems to be to either have another MIDI app open, or to execute MIDIClient.init and MIDIIn.connectAll again.

This is so odd and doesn’t make any sense. Any pointers are highly appreciated.

jamshark70 · December 31, 2021, 12:46am

It’s probably this known bug:

github.com/supercollider/supercollider

MIDI issues on macOS

opened 11:09PM - 24 Nov 21 UTC

closed 09:02PM - 08 Dec 21 UTC

dyfer

bug comp: sclang os: macOS

## Environment * SuperCollider version: 3.12.1 * Operating system: macOS 10.…15 (Catalina), macOS 11.6 (Big Sur) * Other details (Qt version, audio driver, etc.): ## Steps to reproduce ```supercollider MIDIClient.init; m = MIDIOut.newByName("X-TOUCH COMPACT", "X-TOUCH COMPACT"); // testing with a midi cotroller m.latency; // reports the default 0.2 m.noteOn(0, 30, 127); // this turns button LED on // after the first start of SC after the boot, there's about 2s delay for the message to be sent (Catalina and Big Sur) m.noteOn(0, 30, 0); // turn it off // put computer to sleep for about a minute m.noteOn(0, 30, 127); // now the message is delayed by over 40 seconds (the time the laptop was physically asleep) - Big Sur only ``` ## TL;DR As much as I'd like to keep the improved MIDI timing introduced in #4725, that PR seems to introduce issues that IMO are hard to be solved. Unless someone has an idea how to tackle them, I'd suggest to revert #4725 (and possibly release 3.12.2, if desired). ## Expected vs. actual behavior #4725 improved the relative timing of MIDI messages, but introduced 2 (3) new issues: 1. all MIDI messages are delayed approx. 2s after the first run of `MIDIClient.init` after SC starts; re-running `MIDIClient.init` removes that delay. This happens on Catalina and on Big Sur 2. MIDI messages are additionally delayed by the time the computer was asleep since running `MIDIClient.init`. This happens on Big Sur only 3. If we use logical time for MIDI messages, latency calculation should probably be revised (right now the latency value is just added to the resulting logical timestamp). Depending how we deal with the above issues, this point might be moot if we revert #4725. Details: #4725 introduces definition of "starting time" using both SC thread time and time from `AudioHostGetTime()`. This seems like a good approach in principle. The issue is that starting with Big Sur, the time from `AudioHostGetTime()` does not advance when the computer is asleep, while the thread clock does advance. This conceptually similar to the issue solved in #5298 (also see explanation [here](https://github.com/supercollider/supercollider/issues/5168#issuecomment-749277265)) since that issue also dealt with comparing times from different references. Since MIDI message on macOS expects the time as reported from `AudioHostGetTime()`, I don't know how we could reliably calculate logical time, since the SC thread time does advance while the computer is asleep. I guess we could conceivably re-set that offset every time system wakes from sleep, but I'm not sure how to go about it or whether that's the best solution. Regarding problem `1.`, there seems to be some fluctuation in thread timing that occurs only on the first MIDI initialization after SC starts. I don't know where that comes from. I tried posting the offset between `AudioHostGetTime()` and SC thread when initializing MIDI and that offset is consistently off by approx. 2s between the first and the subsequent runs of `MIDIClient.init`. The subsequent runs report offsets that differ only by few ms, which is to be expected, I think, and is not an issue. Only that initial offset is considerably large. (See below for examining that delay) I was trying to fix the issue with clock diverging when computer goes to sleep, but that didn't work since we ultimately need to use the time in relation to `AudioHostGetTime()` to schedule MIDI events. However, my code does post initial time difference between SC clock and system nanosecond clock, where one can observe the difference in offsets between the first and the subsequent initializations of MIDI client: https://github.com/dyfer/supercollider/tree/topic/macos-midi-01

Should be better in the next release. There might be a way to download a test build from github but I can’t find the link right now.

hjh

wolfgangschaltung · January 1, 2022, 3:59pm

Thank you very much, I found the release candidate here. I tested it with both macOS 12.1 “Monterey” on a MacBook Air M1 from 2020, and with 10.14.6 “Mojave” on a MacBook Pro 15" from 2014, and the latency issue is gone

I have read thru according bug #5622. Although it is already closed, does it make sense to add the information to it, that issue 1 (all MIDI messages are delayed approx. 2s after the first run of MIDIClient.init after SC starts; re-running MIDIClient.init removes that delay), does not appear if another app accessing the computer’s MIDI system is already running when starting SC? This happens reproducibly on both of my systems above.