ofxMidi updates

i downloaded the latest rtmidi and compiled the tests and they work on ubuntu 12.04 64bits

ill keep checking :confused:

ups… i just see that only my second post is visible… the first one seems to have faded…

anyway… long story short:

ubuntu 12.04 64 + oF0071

downloaded ofxMidi, compiles but a get a segmentation fault
i downloaded rtmidi 2.0.1 and compiled and runned the tests succesfully

i updated rtmidi in ofxMidi to 2.0.1 using script…

and i get an error when instancing rtMidiIn

RtMidiIn ofxRtMidiIn::s_midiIn("ofxMidi Client");  
// -----------------------------------------------------------------------------  
ofxRtMidiIn::ofxRtMidiIn(const string name) :  
	ofxBaseMidiIn(name), midiIn(name) {}  

…/…/…/addons/ofxMidi/src/desktop/ofxRtMidiIn.cpp|3|error: no matching function for call to ‘RtMidiIn::RtMidiIn(const char [15])’|
…/…/…/addons/ofxMidi/src/desktop/ofxRtMidiIn.cpp|3|note: candidates are:|
…/…/…/addons/ofxMidi/src/desktop/rtmidi/RtMidi.h|153|note: RtMidiIn::RtMidiIn(RtMidi::Api, std::string, unsigned int)|

so i changed the code to

RtMidiIn ofxRtMidiIn::s_midiIn(RtMidi::UNSPECIFIED,"ofxMidi Client");  
// -----------------------------------------------------------------------------  
ofxRtMidiIn::ofxRtMidiIn(const string name) :  
	ofxBaseMidiIn(name), midiIn(RtMidi::UNSPECIFIED,name) {}  

compiles and runs, but i get this…

MidiOutDummy: This class provides no functionality.  
MidiInDummy: This class provides no functionality.  
MidiInDummy: This class provides no functionality.  
ofxMidiIn: 0 ports available  
OF: OF_LOG_VERBOSE: ofxMidiIn: opened port 0   
OF: OF_LOG_VERBOSE: ofxMidiIn: ignore types on : sysex: 0 timing: 0 sense: 0  

so it seems that i have no api installed? doesnt make much sense to me :confused: i had no problems with the rtmidi tests…

can you help me guys? thanks!!! :slight_smile:

so… i couldnt find what’s making my example to crash… but i managed to get my midi working…

im using this version https://github.com/chrisoshea/ofxMidi/commit/1240de0471e02d6d29e26f0e7acce0e0f266a17d
tweaking a bit the make.config… and running!

ubuntu 12.04(64) w oF0071 + rt midi 1.0.15

Dan, ill be glad to help you if you need/want help debugging… i just didn’t know how to continue… :confused:


Hello, Noob alert!

I have the ios ofxmidi example running fine and printing received midi but can’t figure out how to use this data.

I’m used to reading it byte by byte in arduino. Please could somebody give me an idea how to extract the 3 bytes out of the midi stream?

Sorry if this is very basic! And many thanks!!!


Hi Jim, could you please share how you make it work? I can’t figure out the way to send the bytes with the ofxMidiOut.

thanks in advance

Btw, would be great if a MTCSender will be part of the ofxMidi addon

hi, to all! I’m testing ofxMidi on my new notebook , the examples compiles fine but when i launch the apps i receive an “segmentation fault (core dumped)” . i’ve never had this problem before with other machines, ofxMidi works fine on my older pc. I have an Samsung notebook with an Intel i5 2.50ghz 64bit and Ubuntu 12.04 64bit. Maybe ofxMidi do not support 64 bit system?

Tested with a previous @danomatika version , whit the old version i have not this kind of issue… Anybody else has had this issue with linux 64 bit?? i’m going to open an issue on github repo…

He already did in http://forum.openframeworks.cc/t/ofxmidi-updates/2435/94

That’s the idea, but the issue is that RtMidi does not support sending timestamps and there isn’t a cross platform timer ala AudioGetCurrentHostTime() on OSX. I do have a branch that replaces the RtMidi output with PortMidi which includes a timer, can you try that?


The raw byte sending functions take either delta via sendMidiBytes() or a timestamp through sendMidiBytesAtTime().

You run a thread for MTC and the algorithm is similar, except you use ofxMidi::getTime() to get the current timestamp. Note: ofxMidi::getTime() returns milliseconds not nanoseconds, so some adjustment will have to be made.

If you want the raw bytes, they are in the msg which returned by newMidiMessage(): https://github.com/chrisoshea/ofxMidi/blob/portmidi/src/ofxMidiMessage.h

But you don’t have to parse the values yourself, ofxMidi already does this for you …

msg.bytes <-- raw bytes in a vector  
if(msg.status == MIDI_NOTE_ON) {  
   int channel = msg.channel;      
   int note = msg.pitch;  
   int vel = msg.velocity;  
   ...etc ...  

The status byte enums are here: https://github.com/chrisoshea/ofxMidi/blob/portmidi/src/ofxMidiConstants.h

What’s the status of this project? I’m trying OutputExample in Windows 7 on VS2010 and I’ve installed a bunch of Virtual MIDI drivers but I get 0 ports available.

The message “MidiOutDummy: This class provides no functionality” sounds like the project isn’t fully functional yet?

The status? It’s been working fine on all platforms since the spring. I tested on Win 7 with both VS2010 and CodeBlocks+MiniGW and it was working earlier.

From that error message, however, it seems like the rtmidi update from a week ago or so is causing a problem. Can you try an earlier commit or maybe the 0071 tag?

Ok, I identified the problem and the fix is on Github.

I had forgotten to re-add an include to RtMidi.h when it was updated which is needed for the midi api to be detected. I just tested and everything is working again on Win 7.

Phew! that was it indeed, the previous commit worked fine. Thanks!

Howdy all,

Chris has transferred the ofxMidi github repo to my account. The url is now: https://github.com/danomatika/ofxMidi

This means if you have any git clones, you’ll need to update the remote url:

git remote set-url origin git@github.com:danomatika/ofxMidi.git git@github.com:chrisoshea/ofxMidi.git  

If you have a fork, you’ll need to update the upstream url:

git remote set-url upstream git@github.com:danomatika/ofxMidi.git git@github.com:chrisoshea/ofxMidi.git  

Hi. I can’t get ofxMidi to work. It does compile, but I get “MidiOutDummy: This class provides no functionality” at run time and it finds no midi ports. I have just started using OF and C++, so I’m not sure how things work.

In ofxMidiConstants.h I see

	#define __LINUX_ALSASEQ__  

but I think __LINUX_ALSASEQ__ is never used in the project. Should it read __LINUX_ALSA__ ? Then, it seems to imply that Linux users always get Alsa. What about Jack? Am I supposed to replace __LINUX_ALSA__ with __LINUX_JACK__ ? I tried, but it didn’t work any better.

I tried to compile the example-input and example-output projects, but they fail saying:

Makefile|28|../../../libs/openFrameworksCompiled/project/android/paths.make: No such file or directory|  

I don’t have an /android/ folder on my system. I think this is related to OF and not ofxMidi.

If I comment out

#include $(OF_ROOT)/libs/openFrameworksCompiled/project/android/paths.make  

in the Makefile then I get a different error:

-------------- Build: Debug in example-input ---------------  
Using makefile: Makefile  
ls: cannot access ../../../addons/*/libs/*/lib/linux/*.so: No such file or directory  
/usr/bin/ld: cannot open output file bin/example-input_debug: No such file or directory  
collect2: ld returned 1 exit status  

That’s why I decided to ignore example-input and example-output, created my own new project, and copied the three src/* files from example-output to this new project, which fails complaining about the MidiOutDummy as I mentioned above. I don’t know if there are any extra configuration steps on Code Blocks to make the test midi project work.

The old ofxMidi from chrisoshea was working before. Is there anything I can do to make it work? I’m on 32bit Ubuntu 12.04 lowlatency kernel. Thanks!

Yeah sorry. I upgraded to a new version of RTMidi but didn’t notice the defines had changed. It should indeed be __LINUX_ALSA__. I’ll fix that now.

Jack is certainly an option, but no one has wanted it so far and it required more libraries etc to build.

I don’t know why this isn’t working. I haven’t changed anything on the Linux makefiles side. Are you using a newer version of OF? If so, ofxMidi probably just needs a quick update. I’d be happy to take PR as I can’t test right now as my Linux dev machine is at work. I can try it on Monday.

There is no difference between the “old one” and the “new one”, only the repo was moved. The code and commits are the same and, in fact, the last commit was 4 months ago. As it says in the readme, you can easily go back to an earlier stable version using one of the tags.

Ok, Linux api constant updated.

Thanks for the quick reply and update! Some progress on why I’m getting the “dummy” error:

RtMidi.h in line 451 checks if __LINUX_ALSA__ or one of the others constants is defined. But they are all undefined, so it decides to use __RTMIDI_DUMMY__

I don’t know why it’s undefined, but if I drop a
#include “ofxMidiConstants.h”
at the beginning of that file, then it works correctly! In C++, are defines global in scope? Is that include maybe missing? Or is there something else misbehaving? Thanks.

It was undefined because, as you noticed, I included the wrong file in RtMidi.h when I updated RtMidi. It worked fine on OSX, so I didn’t notice. This is now fixed. Thanks for catching it.

Also, defines in header files are not global in scope, only those given as C flags to the compiler. You have to include a header file to see it’s defines.

If anyone was having problem with app startup crashes (segfaults, etc) using ofxMidi on Linux, this is now fixed in the master branch.