midi input

Hi all, I want to control some of the variables in my app with a midi controller and was wondering what the best option is? I almost considered writing a little app in processing to map incoming midi CC to OSC, but I was hoping there’s a better way! I read somewhere that there was the beginnings of a midi addon, though output only - was wondering what the latest situation is?



I’ve used sometimes a processing app that generates osc messages from midi input but it’s a little ineficient. I needed something like that for an app i’m working in so i’ve made an ofxMidiInput.

It uses rtMidi, I’m only using it to receive values from one of those midi usb tables with knobs and sliders, so perhaps the way it’s programmed is not the best for real midi uses.

It’s based on poco events, you just need to extend ofxMidiListener in the class you want to receive the event and overwrite the method newMessage. I’ve seen in other midi input libraries, like the one in processing that it generates diferent types of messages like noteon, noteoff, controllerin… but with rtmidi I only receive the id the value and the number of milliseconds since the last message.


to use this in the diferent platforms some compiler flags are needed:



or just add at the begining of rtMidi.h:

#define __LINUX_ALSASEQ__


-D __MACOSX_CORE__ -framework CoreMidi -framework CoreAudio -framework CoreFoundation

although CoreAudio framework should be already there


-D __WINDOWS_MM__ -lwinmm -llib -lmultithreaded

haven’t tested in windows but from the rtMidi page should be something like that

Wow, great work arturo.
I haven’t installed poco yet so I can’t yet try it. But it sounds like you have it all there.

like the one in processing that it generates diferent types of messages like noteon, noteoff, controllerin… but with rtmidi I only receive the id the value and the number of milliseconds since the last message.

I’m guessing the id represents the type of midi message, i.e.
Note Off, Note On, AfterTouch, Control Change, Program Change etc

and the value is just the corresponding value between 0-127.

Pitch wheel messages have a higher resolution, so they might not be detected properly. Otherwise it looks like it should work with all other messages.

Well, the id is just the number of the control that it’s being activated. I think the type of event has something to do with the timestamp and the values that are being generated, but don’t know how it works.

I also receive another value that might be the type of message, but it’s always the same: 176 for buttons and sliders, and the java library actually generates diferent messages for those…

Hey arturo, thanks for that will hava look. I ended up using Quartz Composer to map the midi to OSC, not the most efficient but quickest to implement. will check out your addon though cos I use it a lot…

Thanks for creating this wonderful MIDI input addon, very useful for a project I’m working on at the moment. Currently, I’m also having QC mapping midi to OSC to use midi information in Open Frameworks, though I would really go for direct input in OF.

Unfortunately, I don’t get Poco added to my project in XCode, which is needed for your addon. Whenever I add Poco libs to a project I get this waterfall of errors telling me that ‘::memcpy’ has not been declared and 99 similar messages for ‘memmove’, ‘strcpy’, etc. etc.

I have the feeling I’m doing something wrong in my build parameters, could anyone post a working xCode project for this addon?

-> EDIT: Great I found this nice threat on poco which solved my problem: http://forum.openframeworks.cc/t/event-handling-±merging-of-with-poco-c++/408/18, sorry for being too fast on my question

Thanks for this - exactly what I needed!

I added:




	virtual void newMessage(int port, int msgType, int id, int value, double timestamp){};  
	void newMessage(const void* sender, ofxMidiEventArgs& eventArgs){  
		ofxMidiEventArgs& midiArgs = (ofxMidiEventArgs&)eventArgs;  
		newMessage( ((ofxMidiIn*)sender)->getPort(), midiArgs.msgType, midiArgs.id, midiArgs.value, midiArgs.timestamp);  

to to give me the midi data types (as integers):
176 Control Change
144 Note On
128 Note Off
224 Pitchbend
240 Sysex Start
247 Sysex End

No luck getting a 14bit number for pitchbend, but maybe this is a problem with rtMidi?

perhaps you already tried this, but in ofxMidiIn.cpp in the newMessage method theres:

if(nBytes == 3){...  

I used that as all the messages the controller I was using had 3 bytes, but surely changing it will work with other types of messages. Please post the changes if you manage to do it so I can add it to the addon.

Wow arthuro, we think alike. I just wrote a Midi class with Poco based events, with the exactly the same class names as you used… I like your style :wink: I guess it’s because i based it on the ofxHttp addon you & chris wrote

:slight_smile: Yes, the httpUtils, mailUtils and this one have really similar structure…

Did you find anything about other kind of messages? I only programmed this with a usb table with some knobs I had by then, but haven’t tried with other devices.

I only used it with a Maudio Trigger Finger, also USB. I thought (and still think) that all midi messages where (program, status, value). Then i just use another class to decode the midi events into values connected to defines representing the different keys, knobs and sliders on the Trigger Finger.

Hi there

Has anyone had any luck getting this to work in CodeBlocks on Windows?

I can’t seem to set the right linker flags,a s I keep getting a whole slew of:

undefined reference to 'vtable for RtMidiIn'  
undefined reference to....  

Some googling around tells me that this is because I don’t have the right compile flags set, but am having trouble figuring out the correct ones.

Have tried linking to the libwinmm.a library - no luck…
Have tried using the compile flags above… -lmultithreaded leads to the compiler balking as it can’t find this…

Any ideas?

Hi (arturo)

I’m having a little trouble building.

My windows Codeblocks (0.06) project has these search directories…


and these files are added

RtMidi.cpp is kicking up a load of errors, starting with

#include <pthread.h>
“No such file or directory”

What am I missing?


hi chris

in RtMidi.h line 43:

#define __LINUX_ALSASEQ__

for windows should be:

#define __WINDOWS_MM__

and for mac:

#define __MACOSX_CORE__

thanks art.

ive done that. now in ofxMidiEvents.h

class ofxMidiEventArgs: public ofEventArgs{

it says build error:
expected class-name before ‘{’ token


the problem is this addon is for 0.057xx not for 006, i thought i’ve already ported this but indeed i didn’t :slight_smile: will port it as soon as i can.

Ah, all you have to do is add this to the top of ofxMidiEvents.h

#include “ofEvents.h”

Great addition Gameover.

I was trying to work out which byte was the channel number, but I noticed when I do a control change on channel 1 it the type is 176, but then I do control change on channel 2 it gives me a type 177. Channel 16 = type of 191

This sort of makes sense. 128+16 = 144

So it might be something like:

128 - 143 = Note Off (channel 1 - 16)
144 - 159 = Note On (channel 1 - 16)

I’ve just found this which confirms it, see bottom of the page

Here is an addition to ofxMidiIn that will work out the correct channel number for a message, and also keep the message type to the right number…

void ofxMidiIn::newMessage(double deltatime, std::vector< unsigned char > *message){  
	unsigned int nBytes = message->size();  
		std::cout << "num bytes: "<<nBytes;  
		for ( unsigned int i=0; i<nBytes; i++ )  
			std::cout << " Byte " << i << " = " << (int)message->at(i) << ", ";  
		if ( nBytes > 0 )  
			std::cout << "stamp = " << deltatime << '\n';  
    ofxMidiEventArgs eventArgs;  
    eventArgs.channel = ((int)message->at(0)) % 16;  
    eventArgs.msgType = ((int)message->at(0)) - eventArgs.channel;  
    eventArgs.channel += 1; // should start at midi channel 1 really  
    eventArgs.id = (int)message->at(1);  
    eventArgs.value = (int)message->at(2);  
    eventArgs.timestamp = deltatime;  


has just made this a little bit more 006ish is more or less the same but now there’s no eventManager.

have also added the changes to differentiate the message type and some conditionals so it compile for the 3 platforms without needing to change RtMidi.h

haven’t really tested it, but it should work just the same as the previous version


thanks art, I will take a look.

Do you have any objections to me changing this from ofxMidiIn to ofxMidi ?

I’ve got to do midi out on the same port, so I was going to write in sending out into the class.

The code I posted that works out the type and channel is wrong, it only works for midi messages of 3 bytes, otherwise it crashes. Some messages I am getting such as midi clock are only 1 byte long.

I also want to add events and broadcasts to be more defined, ie call noteOn or noteOff functions. Maybe you can only listen for those types on certain channels too.

Also in my edit of your class I have…

// channel info  
#define 	MIDI_NOTE_OFF 	          128  
#define 	MIDI_NOTE_ON 	          144  
#define 	MIDI_POLY_PRESSURE 	      160  
#define 	MIDI_CONTROL_CHANGE       176  
#define 	MIDI_PROGRAM_CHANGE       192  
#define 	MIDI_CHANNEL_PRESSURE     208  
#define 	MIDI_PITCH_BEND           224  
// system exclusive  
#define 	MIDI_NOTE_ON 	          144  
// system common  
#define 	MIDI_TIME_CODE	          241  
#define 	MIDI_SONG_POS_POINTER     242  
#define 	MIDI_SONG_SELECT          243  
#define 	MIDI_TUNE_REQUEST         244  
#define 	MIDI_EOX                  247  
// system realtime  
#define 	MIDI_TIME_CLOCK           248  
#define 	MIDI_START                250  
#define 	MIDI_CONTINUE             251  
#define 	MIDI_STOP                 252  
#define 	MIDI_ACTIVE_SENSING       254  
#define 	MIDI_SYSTEM_RESET         255  

I’ll post my changes soon.