Question

My CoreMIDI connection on iOS is apparently fast enough to handle ANYTHING that hits it… if I’m just doing some simple object creation and NSLog. In the UI, I don’t have time to handle everything that comes in. The UI would blow up, or just finish processing too late.

However, I need to do real processing and UI display in response to CoreMIDI inputs. What I’d like is to process the latest messages every, say, 1ms or 2ms. I’ve been doing this with a collection that gets emptied by a timer-fired method every 1ms (processFromServerAsync). One problem is that some messages might fall through the cracks, I think, if I grab and substitute:

NSDictionary *queueCopy = [self.queue copy];
// here the dictionary could get messages not in the queue copy!
self.queue = [NSMutableDictionary dictionary];

I realize that I could handle this by synchronizing with a lock, which is easy to screw up:

-(NSMutableDictionary *)messageQueue {
    @synchronized(self) {
        if (!messageQueue_)
            self.messageQueue = [NSMutableDictionary dictionary];
        return messageQueue_;
    }
}

-(NSDictionary*)clearMessageQueueAndReturnCopy {
    @synchronized(self) {
        if (!messageQueue_)
            return [NSDictionary dictionary];
        NSDictionary *retVal = [messageQueue_ copy];
        self.messageQueue = [NSMutableDictionary dictionary];
        return retVal;
    }
}

However, I’m not convinced that I’m even handling this in the correct way. How is throttling typically done (even outside of Obj-C)? I surely cannot process all those messages in the UI nor the program.

Answer 1

There are some well-established patterns for throttling streams of incoming data. This comes up a lot in finance, where you might have a data feed throwing 100K messages/sec at a system.

You employ a sliding window mechanism to discard redundant messages while ensuring that the client has the latest possible copy of the data. You set your window up over some time period (a few milliseconds) then set up a queue for each data stream (meaning a particular CC, midi note etc.) You start a global timer when the first message comes in. You send that message to the client immediately. If anything else comes in during the window you push it to its queue. The queue has just one entry – the latest value – so you overwrite the queued value with each subsequent update. When the timer ticks (the window is over) you send the latest message out to the client. Then, you send the next message out as soon as it comes in, start a new window and repeat. This gives a reasonable balance between swamping the client and avoiding aliasing of update intervals to the timer window. Aliasing is less of an issue with 1-2ms intervals so a cruder rigid timer approach might work for you.

The critical thing is ensuring that you have separate windows for each data stream. You can’t risk overwriting or ignoring, say, a note off because a control change came in. One timer, one single-entry queue per Midi message number.