building on linux gives Dummy classes

Question

building on linux gives Dummy classes

npisanti opened this issue 6 years ago · comments

Hi,
by building the latest ofxMidi on Linux (Debian 9 / oF master) i always get
MidiOutDummy: This class provides no functionality or MidiInDummy: This class provides no functionality. It seems that the __LINUX_ALSA__ is not defined at the moment that RtMidi is compiled. I tried putting this code in my ofApp.cpp

#if defined(__LINUX_ALSA__)
    std::cout << "NOW LINUX ALSA IS DEFINED\n";
#endif

and it correcly outputs to the terminal that __LINUX_ALSA__ is defined when compiling the app (but RtMidi is still compiled without ALSA support).

I also tried to manually define __LINUX_ALSA__ at line 600 in RtMidi.h and then all the classes behave as usual.

Thanks in advance for the support. =)

Dan Wilcox · Answer 1 · Fri Jul 27 2018 21:16:29 GMT+0800 (China Standard Time)

I think this is an include order issue. Can you try changing the includes in ofxRtMidiIn.h & ofxRtMidiOut.h so ofBaseMidi.h is included before RtMidi.h?

#include "../ofxBaseMidi.h"
#include "RtMidi.h"

Nicola Pisanti · Answer 2 · Fri Jul 27 2018 21:37:56 GMT+0800 (China Standard Time)

i also already tried that. Now i also tried this in both ofxRtMidiIn.h & ofxRtMidiOut.h :

#include "../ofxBaseMidi.h"
#define __LINUX_ALSA__
#include "RtMidi.h"

and i still got dummy classes. I also did make clean and from the console i see that RtMidi is also compiled as one of the last files, so it is strange that __LINUX_ALSA__ it's still undefined when getting there (so there should be another include somewhere that is including the RtMidi.h header before ofxMidiConstants.h , as you suspected ).

Compiling midiInputExample for Release
HOST_OS=Linux
checking pkg-config libraries:   cairo zlib gstreamer-app-1.0 gstreamer-1.0 gstreamer-video-1.0 gstreamer-base-1.0 libudev freetype2 fontconfig sndfile openal libcurl glfw3 rtaudio libpulse-simple alsa gl glu glew gtk+-3.0 libmpg123 
with PKG_CONFIG_LIBDIR=
cat: obj/linux64/Release/.compiler_flags: No such file or directory
Compiling /home/nick/openFrameworks/addons/ofxMidi/midiInputExample/src/main.cpp
Compiling /home/nick/openFrameworks/addons/ofxMidi/midiInputExample/src/ofApp.cpp
Compiling /home/nick/openFrameworks/addons/ofxMidi/src/ofxMidiOut.cpp
Compiling /home/nick/openFrameworks/addons/ofxMidi/src/desktop/ofxRtMidiOut.cpp
Compiling /home/nick/openFrameworks/addons/ofxMidi/src/desktop/ofxRtMidiIn.cpp
Compiling /home/nick/openFrameworks/addons/ofxMidi/src/ofxBaseMidi.cpp
/home/nick/openFrameworks/addons/ofxMidi/midiInputExample/src/ofApp.cpp: In member function ‘virtual void ofApp::newMidiMessage(ofxMidiMessage&)’:
/home/nick/openFrameworks/addons/ofxMidi/midiInputExample/src/ofApp.cpp:108:28: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
  while(midiMessages.size() > maxMessages) {
        ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
Compiling /home/nick/openFrameworks/addons/ofxMidi/src/ofxMidiMessage.cpp
Compiling /home/nick/openFrameworks/addons/ofxMidi/src/ofxMidiIn.cpp
Compiling /home/nick/openFrameworks/addons/ofxMidi/src/ofxMidi.cpp
Compiling /home/nick/openFrameworks/addons/ofxMidi/libs/rtmidi/RtMidi.cpp
Linking bin/midiInputExample for linux64
HOST_OS=Linux
checking pkg-config libraries:   cairo zlib gstreamer-app-1.0 gstreamer-1.0 gstreamer-video-1.0 gstreamer-base-1.0 libudev freetype2 fontconfig sndfile openal libcurl glfw3 rtaudio libpulse-simple alsa gl glu glew gtk+-3.0 libmpg123 
with PKG_CONFIG_LIBDIR=

     compiling done
     to launch the application

     cd bin
     ./midiInputExample
     
     - or -
     
     make RunRelease

Nicola Pisanti · Answer 3 · Fri Jul 27 2018 21:40:46 GMT+0800 (China Standard Time)

PS: up to now i was just using my own fork with all the std:: placed at the right spots, and it was working on oF 0.10, it could be something you changed at the time you changed the listPorts() methods

Dan Wilcox · Answer 4 · Fri Jul 27 2018 22:08:35 GMT+0800 (China Standard Time)

I cleaned some extra includes up, but I'll probably need to put the ofMidiConstants.h includes back.

Dan Wilcox · Answer 5 · Fri Jul 27 2018 22:14:01 GMT+0800 (China Standard Time)

Try adding #include "ofConstants.h" to the beginning of ofxBaseMidi.h.

Nicola Pisanti · Answer 6 · Fri Jul 27 2018 22:32:00 GMT+0800 (China Standard Time)

added, still getting dummy classes

Dan Wilcox · Answer 7 · Fri Jul 27 2018 23:50:04 GMT+0800 (China Standard Time)

I don't have a Linux system right now, so see if you can do some more tests. In the end, we might have to add the define to the addons_config.mk.

Dan Wilcox · Answer 8 · Sat Jul 28 2018 00:12:24 GMT+0800 (China Standard Time)

Can you try adding the following to the appropriate Linus target for your system in addons_config.mk?

ADDON_CFLAGS = __LINUX_ALSA__

You will need to regenerate your project before (re)building. Also, when making changes like this, always clean the project otherwise the RtMidi .o files probably aren't updated.

Nicola Pisanti · Answer 9 · Sat Jul 28 2018 22:32:24 GMT+0800 (China Standard Time)

works good, tested on both linux64 and linuxarmv6l.
The correct flag is:

	ADDON_CFLAGS = -D__LINUX_ALSA__

also in ofxMidiConstants.h you should change

#ifdef TARGET_LINUX
    #define __LINUX_ALSA__

to

#ifdef TARGET_LINUX
    #ifndef __LINUX_ALSA__
    #define __LINUX_ALSA__
    #endif

to avoid getting lots of warnings about __LINUX_ALSA__ being already defined.
If you want i can send you a pull request to close this issue.

Nicola Pisanti · Answer 10 · Sat Jul 28 2018 22:53:59 GMT+0800 (China Standard Time)

oh wait, there is a big problem (that is probably caused by the addons make system).
Basically i think that all the addons share the same CFLAGS, so when one addon CFLAGS change all the other addon for the project are forced to recompile. For example if i compile a project with ofxGui, and then another with ofxGui and ofxMidi, the CFLAGS in ofxMidi force all the addons included in the second project to recompile. This could lead to big wastes of time, expecially on raspberry pis where the compilation times are already long, so if there is a way to make this addon work without adding ADDON_CFLAGS it could be the best solution (as it also already worked in the past, we should just find what specific thing broke the includes in linux).

Dan Wilcox · Answer 11 · Sun Jul 29 2018 04:18:27 GMT+0800 (China Standard Time)

Well, you'll need to find the right order then, as I don't currently have a Linux system.

Dan Wilcox · Answer 12 · Sun Jul 29 2018 04:39:16 GMT+0800 (China Standard Time)

Hah, duh. The problem is that I forgot to re-add the #include "ofxMidiConstants.h" to RtMidi.h after I updated it.

Nicola Pisanti · Answer 13 · Sun Jul 29 2018 18:45:52 GMT+0800 (China Standard Time)

perfect, works well both on desktop and raspberry pi, thanks!

Dan Wilcox · Answer 14 · Sun Jul 29 2018 18:46:42 GMT+0800 (China Standard Time)

It was my mistake to forget to re-add the include. This is now done automatically in the update scripts, so it shouldn't happen again.