ofxMidi updates


hi , i have tested it in Ubuntu 11.04. it works fine for me. Also i 'have used in conjunction with ofxOpeneSceneGraph . In the next days i will release some examples.


I can figure out and work with midi in quite correctly, and it is very cool, but any examples of sync with a daw ?

Does it integrates core midi stuff? or should we handle that part externally ?


[quote=“julien, post:82, topic:2435”]

I can figure out and work with midi in quite correctly, and it is very cool, but any examples of sync with a daw ? [/quote]

No, that’s up to the individual daw. See it’s documentation for whatever control parameters etc they use.

ofxMidi uses RtAudio which uses CoreMidi on OSX, so yes it integrates core midi. Core midi support on iOS is in the works, but not yet usable.


Hi there and many thanks for your answers.
MIDI Clock & sync isn’t really dependant of each DAW.
But because of my previous experiencies with Max6 as external standalone & some daws, indeed, accuracy depends of the daw itself. But it isn’t what I meant.
But ok, I’ll dig that part on my own and post in case of nice solution & process found.

About CoreMIDI, I guess I’d have to follow PGMidi so…


Howdy all,

I’m happy to announce ofxMidi iOS support. Check it out in the develop branch: https://github.com/chrisoshea/ofxMidi/tree/develop

All example project files have been updated & there is now a full featured iOS example. I also uploaded the example app I used to get the hang of how to integrate PGMidi: pgmidi-example.

Api changes include:

  • making the port info functions (listPorts, getPortName, etc) static, shouldn’t affect existing code

  • added ofxMidiConnectionListener class to catch iOS device (dis)connection events

  • added enableNetwork for iOS network midi (works great)


The platform specific code has now been split into src/desktop and src/ios. You may need to update your project files.

Still missing:
* send message delta times, this is currently missing from RtMidi
* iOS virtual midi ports, this is currently missing from PGMidi

If anyone wants to help the respective authors add these things, I’d be happy to update ofxMidi … :stuck_out_tongue:

In any case, I have what I need now for the robotcowboy app. Hoot!


Howdy all,

Just letting you know I merged the ios stuff in develop with the master branch and tagged the last stable commit before ios for 007.

I also updated the iOS example for OF 0071. All other project files should be fine.


I’m currently trying to create a Midi Time Code addon with ofxMidi that let’s you send properly formatted MTC signal to slave other devices/systems to your openFrameworks time + allow you to receive timecode from other apps (in hopes of integrating this into ofxTimeline)

First step is generating the clock, which requires sending messages at very accurate times. I’ve got this to work, but in order to get the time accurate I had to modify RtMidi to allow for sendMessage() to take a custom timestamp (to send messages in the future)

Would it be out of the question to ship a modified version of RtMidi if we add these changes? Custom time stamps is just not supported by the library

Seth mentioned PGMidi now has the ability to send custom times, so if we are down with modifying RtMidi we could allow custom time stamps at the ofxMidiOut level

Here is a rundown of the changes:

void RtMidiOut :: sendMessage( std::vector<unsigned char> *message){  
  sendMessage(message, AudioGetCurrentHostTime());  
void RtMidiOut :: sendMessage( std::vector<unsigned char> *message, UInt64 sendAtTime){  
 ... //timestamp is now set from the parameter instead of   
    MIDITimeStamp timeStamp = sendAtTime;  

Then a few modifications upstream to ofxMidiOut to allow for passing in a custom time.


I’m wondering, don’t you want to integrate MTC into ofxMidi, instead of creating a separate addon for this?


Potentially. I think it’s easier to keep it separate to start with and integrate aftewords.

really cool if it was like class ofxMidiTimeCodeIn : public ofxMidiIn and class ofxMidiTimeCodeOut : public ofxMidiOut

so mtcOut.start() would start broadcasting time code on that port, and mtcIn would be like ofxMSATimer but controlled externally.

either way we need to modify RtMidi. I sent an email to the author so we’ll see…


I’m sorry you just spent a bunch of time on this, because it’s not currently possible with RtMidi.

Back in May, I sent a bunch of fixes upstream to Gary Scavone (RtMidi author), mainly fixes for the Alsa sequencer and bad sysex timestamps on OSX. We also discussed adding settable deltatimes/timstamps when sending.

In the code it’s easy to add to the CoreMidi code, a little bit harder to add to the Alsa code, and the Windows code (being the most primitive api) has to be rewritten form scratch using the Midi Streaming api as opposed to the simple message sending it currently uses.

This was just going to be too much to do at the time, so I didn’t pursue it any further. I know Gary is in the middle of working on the next version of RtMidi, with delta times *maybe* part of it.

In the mean time, if you want this now, I can add in delta times for OSX/PGMidi for now in the dev branch.

In the future, I was thinking about swapping out RtMidi with PortMidi (which Pure Data uses): http://portmedia.sourceforge.net/


Oh, I’m working on the car today (work with my hands not on a keyboard, yeah!) so I can put those changes in later tonight or tomorrow morning. Go ahead and test with your version on OSX if it’s working now.

In double checking PortMidi, it does support timestamps, so maybe I’ll go crazy tonight and convert the ofxMidi desktop backend … (you hit on something I already wanted to do :D).


Hey dan, cool! nothing like some grease under the fingernails to switch things up.

OK – i’m putting the Midi stuff only hold for a bit today. I think the portmidi rewrite would be idea. If you get online tomorrow morning hit me up and we can work on it together?


Also, you don’t need two functions here. You can do the same with one function and a default value:

void RtMidiOut :: sendMessage( std::vector<unsigned char> *message, UInt64 delta = 0){  
 ... //timestamp is now set from the parameter instead of   
    MIDITimeStamp timeStamp = AudioGetCurrentHostTime();  
    timeStamp += delta;  


Hi dan – passing in a delta doesn’t work for this case.

To send perfectly timed messages you need to specify an exact time in the future. timeStamp += delta is still unpredictable. If it helps clarify, here is the class I’m using to send evenly timed spaced midi signals:
(hacky proof of concept sorry!)

class MTCSender : public ofThread {  
	UInt64 lastQuarterSent;  
	UInt64 nextQuarterToSend;  
	ofxMidiOut* outRef;      
	void threadedFunction(){  
		vector<unsigned char> bytes;  
		struct timespec delay;  
		delay.tv_sec = 0;  
		lastQuarterSent = AudioGetCurrentHostTime();  
		nextQuarterToSend = lastQuarterSent + 8333300;  
			outRef->send(bytes, nextQuarterToSend);  
			lastQuarterSent = nextQuarterToSend;   
			nextQuarterToSend += 8333300;  
			delay.tv_nsec = nextQuarterToSend - AudioGetCurrentHostTime() - 6333300;  
			nanosleep(&delay, NULL);  


How is this different from?:

nextQuarterToSend = AudioGetCurrentHostTime() + 8333300;  

In this case, 8333300 is the delta. Is this because you are calling AudioGetCurrentHostTime() outside the thread? I’d much prefer using a delta because it is easy to do for the other platforms …


Hey Dan,

Check that a bit closer –

AudioGetCurrentHostTime() is never used to calculate the time. it’s always specified in even intervals from when the thread started.

it’s impossible to get the loop to wake up at the exact time, so the 6333300 sleep time guarentuees it wakes up with enough time before the marker and then the timestamp is passed with the future date, and the thread goes to sleep again

actually the "lastQuarterSent = AudioGetCurrentHostTime(); " before isn’t even needed.


Ok, I pushed some work to develop. RtMidiOut is updated with a settable delta time and a sendMessageAtTime function that takes absolute time. ofxMidi can now send raw bytes with a delta time or at an absolute time with sendBytesAtTime.

This is prelim only for now as it only works on OSX. I’ll update for Linux, Win, and iOS soon (after family stuff this week).


Thanks dan this works great!

IAC Driver MTC: Time Code 0 [ F1 32 ] 8.3333  
IAC Driver MTC: Time Code 0 [ F1 32 ] 8.3333  
IAC Driver MTC: Time Code 0 [ F1 32 ] 8.3333  
IAC Driver MTC: Time Code 0 [ F1 32 ] 8.3333  
IAC Driver MTC: Time Code 0 [ F1 32 ] 8.3333  
IAC Driver MTC: Time Code 0 [ F1 32 ] 8.3333  
IAC Driver MTC: Time Code 0 [ F1 32 ] 8.3333  


After banging my head into some Windows code in RtMidi, I thought I would step back and try portmidi as well.

There is now a portmidi-branch where portmidi is used for ofxMidiOut on desktop so far. Portmidi includes a cross platform timer and support for timestamps as well as built in latency support.

What we might lose with the library switch would be sending single bytes (not a big deal, better to build the whole message anyway) and the ability to open virtual ports (this is bigger, but only works on Mac/Lin anyway). In my opinion, it would be far easier to add virtual ports to portmidi then to add time stamping to RtMidi.

Only the OutputExample has been updated/tested on OSX so far. If you want to try it with an existing project, you need to add lib/portmidi to your project and remove the subfolders for other OSs (on Mac, remove libs/portmidi/win & libs/portmidi/linux, etc).


hi guys!

anybody tested on ubuntu 12.04, oF 0071?

i took the midiIn example, updated with projectGenerator and
i compiles but i get a segmentation fault
so i commented out all the ofxMidi stuff, and stil i get a segmentation fault…
i tried to debug it but then i get some weird stuff i can descypher :frowning:

thanks! appreciate!