Re: Leisurely processing of incomming MIDI data
Re: Leisurely processing of incomming MIDI data
- Subject: Re: Leisurely processing of incomming MIDI data
- From: Kurt Revis <email@hidden>
- Date: Thu, 31 Mar 2005 21:33:57 -0800
On Mar 31, 2005, at 12:49 PM, Paul Swearingen wrote:
I'm converting a PC MIDI app over to the Mac.
My PC (interrupt time) read procedure grabs the midi data and sends
it to a
circular buffer.
Then, I post a message to the main event loop, and process my MIDI
data,
which can take quite a lot of time, since my MIDI processing is
fairly extensive,
but that's ok, and it all works. Here I keep looping through the
buffer until it's
exhausted.
Should I do the same type of thing on a Mac?
It's a good idea, yes. I certainly do something similar in my apps,
since they don't really care about precise MIDI timing (that is, it
doesn't matter if it takes the app a little while to respond to the
MIDI data, and it doesn't matter if the delay is very consistent or
not). Doing all the processing on a secondary thread, or even the main
thread of the app, is fine for me.
If you wanted something like a synthesizer, where it's important to
have a small and consistent delay between receiving the MIDI event and
playing a sound, then you'd have some more work to do.
Perhaps the MIDIPacketLists essentially act as buffers so I can
eliminate my circular buffers?
If so, it seems like I need to use many lists, and cycle through them.
I don't see how this would work. Your read proc is given a pointer to
a packet list, and that packet list is not guaranteed to remain valid
after the read proc returns. If you want to keep that data around
afterwards, you need to copy it somewhere else... which might as well
be your own circular buffer.
The read proc is a high priority thread, and not even the thread of my
program, -- I've read (red)
I need to be fast during this routine.
It IS a thread running in your process (program), although CoreMIDI
creates it for you. So if you block in that thread or take a long
time, it isn't catastrophic -- you probably won't be hurting anything
in the system other than yourself. The constraints for audio-related
threads are much more stringent.
That said, it is best if your read proc gets its work done and returns
as quickly as it can.
What I don't understand is the mechanism whereby I can grab data
quickly, then process it
at my leisure . . . It seems like there should
be a simple way to do this by posting messages, perhaps???
That part is entirely up to you -- there's nothing built-in to CoreMIDI
or CoreAudio to handle cross-thread communication. There are a number
of different ways you could do it, depending on what environment you're
in (command-line tool, Carbon app, Cocoa app) and what APIs you're
using (pthreads, CFRunLoop, NSRunLoop, etc.) What part are you having
problems with?
--
Kurt Revis
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden