On Mar 6, 2013, at 7:54 AM, Haynes Electronics < email@hidden> wrote:
The program closely follows the CABook - here's the callback part : MIDIInputPortCreate( midiInfo.client, CFSTR("Input port"), MIDIEchoReadProc, &midiInfo, &midiInfo.inPort), and the read proc : void MIDIEchoReadProc(const MIDIPacketList *pktlist, void *refCon, void *connRefCon) { MIDIEchoStruct *midiInfo = (MIDIEchoStruct*) refCon; --- do midi processing --- works --- echo to destination --- works --- printf to console --- works [myTextField setIntValue:midiInfo->mVelIn];doesn't work - or - [self myWriteToTextfieldMethod];doesn't work - self is undefined
Your callback is a C function, not an instance method. Of course self is undefined.
}
(I can manually read out the values in my text field by pressing an IBAction button, so the values are available) How can I get the midiReadProc to communicate with the rest of my program ?
It sounds like you need to work on your Objective-C fundamentals. If the object that sets up the MIDI callback struct is the one you want to message (or has a handle to it), you can stuff a pointer to that object into your MIDIEchoStruct. Otherwise, you could post a notification, or if you know you only have one window, adopt the singleton pattern for its window controller.
But this being audio, you were probably on the right track having the UI layer read the current state rather than pushing the current state to the UI from your callback. I'm not sure if MIDIEchoReadProc is executed in a realtime context, but if it is then sending an ObjC message can introduce latency and is not a good idea.
Instead, your ReadProc should append values locklessly to a buffer, and your UI layer should periodically (perhaps using NSTimer) read the newest values from this data structure. In other words, a producer/consumer model where readers can't block writers.
--Kyle Sluder |