MIKMIDIDeviceManager.shared.connect event handler called on main thread

[makaGeorge]

Hi,

I'm having a small problem due to the fact the event handler (when midi data is received through a source) is executed on the main thread. Any UI intensive action from the system (like presenting a viewcontroller, adding a subview or animating a view) will delay midi messages which is especially noticeable in the case of midi clock messages.

I've quickly tested just removing the Dispatch.main line and it seems to solve the problem but I don't know if this will cause other problems as I really have no clue why the event handler is being called on the main thread...

This is what I've changed for the test... maybe it should call the event handler on another background thread?

- (void)sendCommands:(NSArray *)commands toEventHandlersFromSource:(MIKMIDISourceEndpoint *)source
{
	dispatch_async(self.handlerTokenQueue, ^{
		NSArray *handlerPairs = [self.handlerTokenPairsByEndpoint objectForKey:source];
		for (MIKMIDIConnectionTokenAndEventHandler *handlerTokenPair in handlerPairs) {
			MIKMIDIEventHandlerBlock eventHandler = handlerTokenPair.eventHandler;
			//dispatch_async(dispatch_get_main_queue(), ^{
				eventHandler(source, commands);
			//});
		}
	});
}

Thanks!!

[armadsen]

I made this choice (a long time ago) so that the average user of the API wouldn't have to worry about updating UI (UIKit/AppKit) stuff in the event handlers. Simply removing that is probably fine as long as you take responsibility for making sure that any work you do in your eventHandler block/closure is dispatch to the appropriate queue (e.g. the main queue for UI updates). I'm going to close this since I think it's mostly a question, but I have opened #339 to track an enhancement request to allow people to specify which queue event handlers are called on.