Re: Trying to understand basics of CoreMidi -1
Re: Trying to understand basics of CoreMidi -1
- Subject: Re: Trying to understand basics of CoreMidi -1
- From: Robert Grant <email@hidden>
- Date: Sat, 16 Aug 2003 17:05:31 -0400
Hi Jai,
I'll give it a crack...
On Friday, August 15, 2003, at 05:41 PM, Jai Hall wrote:
I am currently working with OpenGL in C++ and want to receive midi
note on
and off messages to trigger object methods in my software. I have been
reviewing the supplied CoreAudio example code "SampleTool" which simply
echos midi in to midi out on a midi hardware device. I thought it
would be
pretty straightforward to borrow from this, but, it was confusing.
I'd like to ask if someone could briefly walk me through what is
happening
conceptually. Or, rather than have someone else do all the work, I'll
list
what it looks like to me and maybe someone can just correct me.
1) MIDIPortRef, MIDIEndpointRef, and a generic channel are inited to
nulls
for later use by the Read procedure.
2) The next significant stuff that seems to happen are the creation of
the
MIDI client, input port, and output port. MIDIClientRef and
MIDIPortRef are
initialized to null so a dynamic reference to them can be returned by
the
MIDIClientCreate, MIDIInputPortCreate, and MIDIOutputPortCreate
procedures.
Why are the client and input port references created here, but the
output
port ref is created at up at the beginning of the program (MIDIPortRef
gOutPort = NULL;) and not here? (Sorry if these are really obvious).
The gOutPort etc are created globally so that they can be referenced in
the MIDIInputProc. It saved the sample code writer from passing them
down in a struct through the refcon. One could argue that a better
example would have shown how to use the refcons - especially as you've
become confused about them :-)
3) There's some code about the devices, not really of concern to me
(right
now).
4) Next there is the destination code:
n = MIDIGetNumberOfDestinations (); // What is a destination in
relation to
an endpoint?
Endpoints cover both MIDI sources and destinations (MIDI In and Out)
Seems like this code polls possible destinations (of the
MIDIOutputPort?),
then prints to the stdio where the MIDI info went?
Actually MIDI can be sent through a MIDIOutputPort to any destination.
5) I see that the MyReadProc is supplied to the MidiInputPort when it
is
created. This handles incoming MIDI data.
And can receive MIDI input from any MIDI source and the example
connects all the sources to the MIDIInputPort (and thus the
MIDIReadProc).
6) Finally getting back to the MyReadProc:
This is the engine doing most of the work?
Yep. The other stuff was just wiring the MIDI endpoints up to the
application.
This procedure asks for a MIDIPacketList, a refCon, and a connRefCon.
What
are the refCon and connRefCon? I see they are related to
MIDIInputPortCreate
but am confused as to what they do in this procedure.
refCon is your user data pointer. You would specify it in the
MIDIInputPortCreate(). The connRefCon allows you to associate some user
data to each MIDI source connection. You would specify it in
MIDIPortConnectSource().
Next, if there is a proper output port and destination it executes
MIDIPacket *packet = (MIDIPacket *)pktlist->packet; what does this
snippet
do?
Casts away const.
Next, it rolls through the packet list data; if it's note off or system
common it goes on to the next packet with packet =
MIDIPacketNext(packet);
????
The MIDIPacketList contains a packed list of MIDI packets or messages
that all arrived at the same time. A MIDI packet can have 1 to many
bytes. Check out
http://www.midi.org/about-midi/table1.shtml for some
basic info about MIDI messages.
Finally, it sends data to the hardware output port with MIDISend,
gDest,
pktlist).
Yep.
Finally, sorry, I know it's bad netiquette to send long-winded
messages,
but, I wasn't sure on how to go about asking my question. If there's a
normal way of doing so, such as commenting code snippets or something,
let
me know and I can resubmit my questions. In the end, I'm looking to
capture
realtime midi notes, translate them into hex or note numbers, to
trigger
object methods in my graphics program like any other keyboard input.
If I were doing this in Cocoa I would have a switch statement in the
MIDIInputProc that would fire off messages using the friendly
-[NSObject performSelectorOnMainThread:] which would let me get out of
the MIDIInputProc thread. I'm sure there's some way of doing something
similar in C++. I would heartily recommend you take a look around the
CoreAudio Swiki:
http://www.mat.ucsb.edu:8000/CoreAudio - there's lots
of example code as well as discussion of what you can and can't do in a
MIDIReadProc.
Good luck,
Robert.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.