thestk/rtmidi

A set of C++ classes that provide a common API for realtime MIDI input/output across Linux (ALSA & JACK), Macintosh OS X (CoreMIDI) and Windows (Multimedia)

rtmidi's Issues

RtMidi compilation error on OS X

I am working through the Seven More Languages in Seven Weeks book. The Lua chapter has some interfacing code between Lua and C++, and they use RTMidi for the example.

I am getting the following error. I have Lua and RtMidi both installed through Homebrew. I am running macOS Sierra on a late 2016 Macbook Pro. Any help would be appreciated. Thanks!

$ make
Scanning dependencies of target play
[ 50%] Building CXX object CMakeFiles/play.dir/play.cpp.o
[100%] Linking CXX executable play
Undefined symbols for architecture x86_64:
  "RtMidiOut::RtMidiOut(RtMidi::Api, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1
:allocator<char> >)", referenced from:
      ___cxx_global_var_init in play.cpp.o
  "RtMidiOut::~RtMidiOut()", referenced from:
      ___cxx_global_var_init in play.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [play] Error 1
make[1]: *** [CMakeFiles/play.dir/all] Error 2
make: *** [all] Error 2

docs link in the README is pointing to the wrong dir =)

looks like the link to the docs is broken in the current README.md, pointing to a doc/html dir that does not exist.

RtMidi.cpp not placed in default path

eg . must specify ../RtMidi.cpp for gcc compiler options when compiling the test cases. is there a directory RtMidi.cpp can be moved to which is in the default shell path?

Homebrew formula

It would be nice to have a homebrew formula to install easily RtMidi on the development machine. I guess the bug #32 should be fixed first.

Hierarchical approach to sorting MIDI ports

Hi,

on some of the supported systems the MIDI ports are hierarchically ordered. On some systems we have different APIs, on others ports are assigned to clients or devices. So it would be nice to have a tree-like structure to assist users to find the right MIDI port. I don't think it would be a good idea to hardwire this relationship to any assumption about the “hardware” structure. Just a superdevice-subdevice relationship would be ok. This would include to have RtMidi branching devices which are neither input ports nor output ports.

The interpretation of this relationship should be left to the API that is used. So it should not be a problem if Windows has an API/Port structure while ALSA provides API/Client_or_device/port. Some network defined protocol might use Server/Network_Port/API/client_or_device/port. It might be more complex if the protocol allows to reexport MIDI ports. I think the API for such a feature can be realised with just a view functions:

Hierarchical_device * GetRootDevice();
std::list<Hierarchical_device *> GetSubDevice(Hierarchical_device *);
Hierarchical_device * GetSuperDevice(Hierarchical_device *);

The first function could be ommitted by calling GetSubDevice(null_ptr).

Such an API could avoid the problem that are discussed in #6 and #11 .

Unable to find MIDI sources on Debian Linux

Currently I am trying to use a MPK Midi Keyboard with a BeagleBone Black. The BeagleBone runs Debian 7.5.

I'm able to find the MIDI Device by entering $ amidi -l

Dir Device    Name
IO  hw:1,0,0  MPK mini MIDI 1

and $ cat /proc/asound/cards

 0 [Black          ]: TI_BeagleBone_B - TI BeagleBone Black
                      TI BeagleBone Black
 1 [mini           ]: USB-Audio - MPK mini
                      AKAI PROFESSIONAL,LP MPK mini at usb-musb-hdrc.1.auto-1.2, full speed

I am even able to get some midi input with $ cat /dev/midi1.

I compiled the examples to see if rtmidi can connect to my keyboard, but the number of devices stays always zero.

$ ./midiprobe 

Compiled APIs:
  Linux ALSA

Current input API: Linux ALSA

There are 0 MIDI input sources available.

Current output API: Linux ALSA

There are 0 MIDI output ports available.

Does anyone knows a solution to this problem or can point me in the right direction? Currently I'm clueless.

Thanks

ks.h and ksmedia.h should not be included in RtMidi

The two files are part of the Windows API and should not be provided with RtMidi. Overriding the system supplied version with another one will cause problems in the long run.

You should also be aware that DLLs are only linked at runtime. There exists always some glue code between the DLL and the software so that the Windows ABI does not
necessarily have to comply with the binary interface of the API headers.

Array index overflow in Midi(In|Out)Jack :: getPortName

The getPortName functions of the JACK backend use the port number unchecked and thus may read after the end of the ports array without notice.

This may be a security issue for applications that allow remote access to the port selection.

Note: There is no way to protect the code from the application side. The JACK backend suffers from the same race condition as the ALSA backend: If a port is added or removed between two calls to RtMidi the serial port number may have changed some ports may have been removed from the list. New ports might appear if the type of ports is changed during runtime and – depending on the internal operation of jack_get_ports – if a client adds ports (I didn't check the latter as it doesn't change much). Thus, it is not possible to circumvent this problem using getPortCount().

P.S.: I noticed this issue while writing the JACK implementation for #21 .

Cannot get number of ports without an object

I think it should be possible to query the number of available ports using a class function. This would allow one to see if MIDI is available before constructing objects which may have expensive initialization code to create a client. For instance, on my system, MIDIClientCreate (in MidiInCore::initialize called from MidiInCore:: MidiInCore()) can take several seconds to complete. As far as I can see, the port count functions under all APIs except maybe JACK do not require a client to be created.

isPortOpen works only on physical ports ?

I tried u sing isPortOpen with virtual ports and they always seem to return false, is that normal ?

Makefile.in contains archaic reference to RtError.h

deleting RtError.h from Makefile.in precludes failure of make

Overflow in timestamp computation

When compiling the library using clang's integer overflow sanitiser (-fsanitize=integer), it complains at runtime with the following error message:

RtMidi.cc:1275:11: runtime error: unsigned integer overflow: 1484769370242715 - 6872316419617283935 cannot be represented in type 'unsigned long long'
SUMMARY: AddressSanitizer: undefined-behavior RtMidi.cc:1275:11 in

This message comes from the fact that in

rtmidi/RtMidi.cpp

Line 1275 in edb963b

time -= apiData->lastTime;

apiData->lastTime can be bigger than time.

A workaround is then to change the line to time -= std::min(time, apiData->lastTime)

This happened on my system which is linux (debian testing) using the alsa backend.

MIDI Loop

Hi,

Everything I send thru a MIDI out virtual port is received on the MIDI in virtual port. Is is normal?

Thx,

Nuno

Win10 and Microsoft GS Synth

Hello
I had trouble using the GS Synth in Win10 (it gave an error when opening the port).
I googled a while and found this, which solved my problem:
http://stackoverflow.com/questions/31752786/midioutopen-on-windows-10-using-microsoft-gs-wavetable-synth-fails
I added a line to my code and the synth now plays MIDI data, however I think it could be managed directly in RtMidi.
Thanks for your attention
Nicola Cassetta

change pkg-config name to rtmidi

I have found many people configure autotools with

PKG_CHECK_MODULES(RTMIDI, rtmidi)

https://gist.github.com/nils-werner/4d1e935b474f525835b5

But I can find any repo with such configuration. Installing from repo it is librtmidi. Is there any plans to change it or any branch (stable/unstable) with that changes?

Release new version

Since the API change (particulary in this commit 2c7a666), would it be possible to release a new version?

__WINDOWS_MM__Could not recognize

After I downloaded your demo, I took Rtmidi out of the project, but I didn't recognize the WINDOWS_MM, and I didn't know if I needed to copy some files.

makefile fixes

couple Makefile.in fixes for a cleaner build on linux

dir-destdir-rterror.patch

• remove RtError.h - "embedded directly in RtMidi.h"
• tell install to create missing directories - e.g. fakeroot
• use DESTDIR instead of PREFIX for make install - https://www.gnu.org/prep/standards/html_node/DESTDIR.html

No port names on ALSA

On ALSA (asound), port names returned are of the form <client name> <client id>:<port id>. The cid:pid pair is unique, but this makes it hard to look for ports by name. Mentioned in #54, but I thought it would be better to move the discussion here.

Map between Linux USB id and RtMidi port name?

This is turning out not to be so simple. I am trying to write a udev rule to start an rtmidi based application when a specific USB vender + device id is seen in a hot-plug event. The only place I've found where ALSA bridges between the two domains is the /proc/asound//usbid file. So, in theory it's possible to exhaustively check all usbid files on hot-plug until I find the match. However, that doesn't get me to any reliable way of determining the ALSA port name required by rtmidi itself. This naming convention seems to change depending on the version of RtMidi in use and I've found no way to synthesize it from data under /proc/asound. Am I missing something obvious? Can anyone suggest a way to easily determine the RtMidi port name from the USB device id?

App freezing randomly on MacOSX

I have random freeze on my app when creating virtual port on MacOSX. It is very strange because the application icon is displayed when going though cmd+tab but I can't find the process when doing ps aux | grep MyApplication.
Is anybody reproducing this issue?

midiout tutorial : first midi message sent, then nothing

Hi all,

I had issue using the tutorial midiout.cpp with my audio gears.
It compile fine.
It seem to run fine but only the first midi message seem to be sent.
I use a debian 3.2.0-4 kernel, an EDIROL UM-1SX, a novation x-station and a Korg Electribe R.

$ uname -a
Linux yoyz-laptop 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64 GNU/Linux

This kind of message ( from line 59 ) is not sent to my usb midi device.
message[0] = 0xF1;
message[1] = 60;
midiout->sendMessage( &message );

It is sent when I modify the code this way :

message.push_back( 0xF1 );
message.push_back( 60 );
midiout->sendMessage( &message );
message.clear()

I had trouble to understand why it fails, because the first message is sent ( with push_back), but there is no other message sent....
So using std::vector with message[0]=stuff1; message[1]=stuff2; midiout->sendMessage( &message ); may not be suitable for everyone.

Regards,

Johann

error running autoconf

Hi,
When trying to run autoconf on a debian machine I get the following errors :
configure.ac:6: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:14: error: possibly undefined macro: AM_PROG_AR

I am running autoconf v 2.69

Thanks

Linking issue

I found a solution for linking issues under VS2015.1. Dont forget to compile against v140_xp.

ALSA reports wrong port count after ports have been opened

RtMidiIn::getPortCount() with ALSA: if I'm invoking this method after some Midi In and Out ports are already open, rather than only the actual number of existing Midi inputs, this function returns the total sum of the exsisting Midi In ports (whether opened or not) plus the number of opened (and only opened) Midi Out ports.

In my case, I have 5 Midi inputs and 5 Midi outputs, my application opens all inputs and only 2 outputs. If I call RtMidiIn::getPortCount() after all ports have been successfully open and working, I get 7 (5 + 2) instead of 5.

I'm doing this because I'm polling in order to check whether a Midi device has been added or removed, in which case the program should close all ports and reopen them. Since I need to open all Midi Inputs and only the specified two Midi outputs, I'm checking the number of inputs.

The port count is reported correctly if no ports are open. And this issue only applies to ALSA. Everything is ok with Windows.

Change RtMidiCallback to be an alias of std::function

Hi,
I would like to use lambdas as an RtMidiCallback. To do it for me all it took was to change RtMidiCallback typedef to:
using RtMidiCallback = std::function<void(double timeStamp, std::vector<unsigned char> *message, void *userData)>;
Although a compiler would need to support at least c++11 - I do not know but maybe it could be a problem for someone. Or maybe there is another way?
If you want I can create a patch or pull request, though it would be a small one.
Cheers,
Michal

Linker errors with compiled libraries on OS X

On OS X 10.9.3 I'm having issues linking the compiled rtmidi libraries, static or dynamic.

Both cause me to get a linker error no matter what API function I call from my application.

I've defined MACOSX_CORE.

Undefined symbols for architecture x86_64:
  "RtMidi::getCompiledApi(std::vector<RtMidi::Api, std::allocator<RtMidi::Api> >&)", referenced from:
      Application::Application(int&, char**, QElapsedTimer&) in Application.o

Two same connections on WIN

We experience that when we try to connect a device two times.

RtMidiIn * rtMidiIn1 = new RtMidiIn();
rtMidiIn1->openPort(0);

RtMidiIn * rtMidiIn2 = new RtMidiIn();
rtMidiIn2->openPort(0);

then we get hard crash.

It is hardcrashing on win platform on mac it works nicely. ( ubuntu I havent tried yet)

Any idea why it is crashing?

CoreMIDI: rtmidi believes virtual midi port open after it has been closed

When trying to open a virtual port after having closed a virtual port rtmidi spits out an error saying:

MidiOutCore::openVirtualPort: a virtual output port already exists!

I believe this is because MIDIEndpointDispose is not cleaning out data->endpoint in the closePort code:

void MidiOutCore :: closePort( void )
{
  CoreMidiData *data = static_cast<CoreMidiData *> (apiData_);

  if ( data->endpoint ) {
    MIDIEndpointDispose( data->endpoint );
  }

  if ( data->port ) {
    MIDIPortDispose( data->port );
  }

  connected_ = false;
}

Perhaps I am missing something?

Error in "sendMessage()" while sending SysEx messages longer than 258 bytes on MacOSX

Hello!

I have a self-made cross-platform app, developed with Python 3.4, and I use rtmidi to send SysEx messages to configure an Arduino UNO.

The configuration message has a dinamic size up to 1024 bytes.

On windows and linux, everything works like a charm, but on MacOSx (tried with El Capitan) I get an error every time I try to send a message longer than 258 bytes (It's tricky to know if this is the actual limit, but it won't send 260 bytes, so it's either 258 or 259).

The error is "MidiOutCore::sendMessage: could not allocate packet list", which I found to be set by a null pointer to a packet on line 1049 of RtMidi.cpp.

From what I can see around those lines of code, the pointer is set by CoreMIDI's method MIDIPacketListAdd(). And in the documentation reads:
"Returns null if there was not room in the packet for the event; otherwise returns a packet pointer which should be passed as curPacket in a subsequent call to this function."

If further info is needed, I'll be around.

Windows: setting filters creates wrong timestamps

Hi
In the Windows version the midi in event time stamp is calculated for all the coming events, including the event filtered.
Supposing you use ignoreTypes to get rid of active sense. The event time stamp is calculated anyway and the next event timestamp will be calculated from the active sense and not from the last non-filtered event.
This make the timestamp wrong since it may refers to events filtered out.

This can be fixed moving the line of code
apiData->lastTime = timestamp;

  else apiData->message.timeStamp = (double) ( timestamp - apiData->lastTime ) * 0.001;
  // Remove this
  //apiData->lastTime = timestamp;

  if ( inputStatus == MIM_DATA ) { // Channel or system message

after the filters (line 2012)
just before the line related firing the callback

    else return;
  }

  // Moved here!
  apiData->lastTime = timestamp;

  if ( data->usingCallback ) {
    RtMidiIn::RtMidiCallback callback = (RtMidiIn::RtMidiCallback) data->userCallback;

In this way filtered events are not calculated and the deltatime is related to the unfiltered events
regards

Virtual port connection status

I noticed that there is an isPortOpen() function which relays the connected_ bool but as the code stand this appears to only provide connection status for non-virtual ports. Is this intentional or should isPortOpen() return the connection status of a virtual port?

When receiving MIDI clock on MIDI IN, deltatime varies when MIDI OUT is being used

Hi,

I'm facing a problem which i'm not certain about who's fault is.

I'm using RtMidi to receive and send MIDI. My app runs on Windows and Mac. The app receives the MIDI clock on MIDI In and calculates the BPM. It relies on deltatime to do it. On the other hand, commands are sent via MIDI out to the app. Everything perfect on Mac.

On Window however, everytime I start send MIDI out messages, the deltatime of the midi in callback is affected and the result is a bad calculation of the BPM everytime commands are being sent. This doesn't make sense. Is it supposed to be related? I'm using LoopBe as MIDI driver.

I would definitely love to hear your opinon here.

Regards,

Nuno

Missing "extern "C""'s?

Also: thestk/rtaudio#62

Can't compile RtMidi in QT Creator

Hi!
I am new in programming. I did not can to compiled in QT Creator...

Gives you the error:
warning: /: linker input file unused because linking not done
error: error: .o: No such file or directory
error: [my_rtmidi] Error 1

the problem was solved!!!

File my_rtMidi.pro:...
DEFINES = UNIX_JACK
HEADERS = RtMidi.h
SOURCES = main.cpp
LIBS = -L/usr/lib/x86_64-linux-gnu/lib -ljack

configure error

After installing autoconf I run ./configure and get the following error:

configure: error: cannot find install-sh, install.sh, or shtool in config "."/config

Any idea?

[bug][linux] If we open MidiOut before MidiIn , no input message are received

step to reproduce:

take the code below (which is no more no less than example code in documentation in which we've added a RtMidiOut that we only open) and compile it, we can't receive any midi message from RtMidiIn

However without , or if we open RtMidiOut AFTER RtMidiIn, then everything is fine

I'm using an up to date Ubuntu14.04

Linux desktop 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

// qmidiin.cpp
#include <iostream>
#include <cstdlib>
#include <signal.h>
#include <unistd.h>
#include "RtMidi.h"

static unsigned INPUT_PORT_THAT_WORK_FOR_ME = 1;
static unsigned OUTPUT_PORT_THAT_WORK_FOR_ME = 1;

bool done;
static void finish(int ignore){ done = true; }
int main()
{
    RtMidiIn *midiin = new RtMidiIn();
    RtMidiOut *midiout = new RtMidiOut();
    std::vector<unsigned char> message;

    int nBytes, i;
    double stamp;
    // Check available ports.
    unsigned int nPorts = midiin->getPortCount();
    if ( nPorts == 0 ) {
        std::cout << "No ports available!\n";
        goto cleanup;
    }

     // with this line,   midiin does not receive anything anymore, comment this line
    // and everything is fine .... 
    midiout->openPort(OUTPUT_PORT_THAT_WORK_FOR_ME);  

    midiin->openPort(INPUT_PORT_THAT_WORK_FOR_ME);
    midiin->ignoreTypes( false, false, false );

    done = false;

    (void) signal(SIGINT, finish);

    std::cout << "Reading MIDI from port ... quit with Ctrl-C.\n";
    while ( !done ) {
        stamp = midiin->getMessage( &message );
        nBytes = message.size();
        for ( i=0; i<nBytes; i++ )
            std::cout << "Byte " << i << " = " << (int)message[i] << ", ";
        if ( nBytes > 0 )
            std::cout << "stamp = " << stamp << std::endl;
        // Sleep for 10 milliseconds ... platform-dependent.
        usleep( 10 );
    }
    // Clean up
cleanup:
    delete midiin;
    return 0;
}

Possible data loss in the JACK backend.

The output ringbuffer is not flushed when the jack client is closed. If the JACK connection thread did not deliver all data, the remaining data is lost.

Sometimes creates really large SYSEX message when it is not

On occasion I seem to get really large sysex messages in callback when actual message is not even close to 600 bytes. We have a system that never has a SYSEX message greater than 104 bytes, yet we can get suddenly extremely large sysex messages.

I am trying to get more data to share, but has anyone else encountered this issue?

Is it possible to play a sound though the audio driver?

I am currently on linux and I am playing around with rtmidi. Now I was able to play a sound though my digital piano but I am wondering if I can also output the sound though my speakers?

When my digital piano is not connected I still get one device with getPortCount(); I assumed that is my audio driver. The device name is Midi Through:0 which is somewhat strange.

But I don't hear any sound and I am not sure if that is the intended behavior. Can I play midi sounds though my audio driver with rtmidi? Or do I need another library for this?

"vector iterators incompatible

Hello rtmidi!
I get this error when running rtmidi on Windows:

 vector iterators incompatible

The error originates on line 344 in RtMidi.cpp, with this code:

 std::vector<unsigned char> *bytes = &(inputData_.queue.ring[inputData_.queue.front].bytes);
 message->assign( bytes->begin(), bytes->end() ); // this is where the error happens

It looks to me like the queue object may be corrupt. The size is 1000, and ringsize is 1000, which I believe means the queue is full. However, front is 943 and back is 950, which I wouldn't expect if the queue was full. I think if the queue is full, front and back should be only one apart.

My first guess is that this is a thread safety issue that might be solved by using a mutex to safely access inputData_.queue. However, I know RTMidi has been used for a long time by lots of people, so it would surprise me if was really the issue.

The midi input example at http://www.music.mcgill.ca/~gary/rtmidi/ is quite straightforward. Is there anything tricky about midi input that I might have missed that would help to prevent the corruption of inputData_.queue?

Error Callback gets never called in Windows

In class MidiApi the private member bool firstErrorOccurred_ is not initialized, causing it to be initialized to true. The consequence of this is that when the error callback has been set using setErrorCallback(), the callback function will never be called.

This member should be explicitly initialized to false:
bool firstErrorOccurred_ = false;

This occurred on Windows 10, with Visual Studio 2015

Warning C4996 'strdup': The POSIX name for this item is deprecated (VS2015)

Warning C4996 'strdup': The POSIX name for this item is deprecated. Instead, use the ISO C and C++ conformant name: _strdup. See online help for details rtmidilib c:\dev\rtmidi-master\rtmidi_c.cpp line:70

This may or may not be a problem. Microsoft is very fuzzy about the actual meaning of "deprecated".

I have problems when instantiating RtMidiIn object.

My problem is kind of similar to this:
#31

I am using Qt to compile RtMidi and my os is windows 8.1. I was trying to build a MidiReceiver class that would be communicating with MidiAnalyzer class and I noticed this:

std::cout<<"begin receiver init" << mAnalyzer->getName() << std::endl; midiIn = new RtMidiIn(); std::cout<<"begin receiver init" << mAnalyzer->getName() << std::endl; midiOut = new RtMidiOut(); std::vector<unsigned char> message;

this code crashes (it crashes everytime I try to access to mAnalyzer (which is and instance of my other class MidiReceiver)

Also, this crashes too (like the other link):
std::cout<<"begin receiver init" << mAnalyzer->getName() << std::endl; midiOut = new RtMidiOut(); midiIn = new RtMidiIn(); std::vector<unsigned char> message;

but this doesn't (as long as I don't try to access mAnalyzer):

std::cout<<"begin receiver init" << mAnalyzer->getName() << std::endl;
midiIn = new RtMidiIn();
midiOut = new RtMidiOut();

std::vector<unsigned char> message;

This is MidiReceiver.h:

class MidiReceiver {
private:
RtMidiOut *midiOut;
RtMidiIn *midiIn;
MidiAnalyzer *mAnalyzer;
int name = 2;

public:
MidiReceiver();
void init();
static void mycallback(double deltatime, std::vector< unsigned char > *message, void *userData);
void publicCallback(std::vector< unsigned char > *message,double deltatime);
};

endif // MIDIRECEIVER_H

It crashes in init function which sets up callback etc...
It is very strange it seems that calling "new RtMidiIn()" destroys everything in my class...

Thanks in advance for the help!

PS: I'm sorry I couldn't figure out the "insert code" button

Expose connection status

It'd be nice for the API let you see if an instance has an open port or not. In 1.x all the drivers had a Boolean connected_ value they used internally. In 2.x it seems like most use data->port == NULL for the same purpose. I'd love to avoid duplicating the logic.

Novation LaunchKey Mini not detected.

I'll update this with details in the next day

No configure script

The readme suggests using a configure script:

On unix systems, type "./configure" in the top level directory, then "make" in the tests/ directory to compile the test programs.

But it's not included in the repo. Seems like either the docs need to be updated or the file added.

Get client name API ?

In alsa I can get the midi client names
alias lsmidi='aplaymidi -l'

 Port    Client name                      Port name
 14:0    Midi Through                     Midi Through Port-0
 20:0    APC MINI                         APC MINI MIDI 1
128:0    TiMidity                         TiMidity port 0
128:1    TiMidity                         TiMidity port 1
128:2    TiMidity                         TiMidity port 2
128:3    TiMidity                         TiMidity port 3

Is there any way to get the client name ? - if not would it be possible to add a way ?

make gives error 'firstErrorOccured_' was not declared in this scope

After cloning this repo, running autoconf, and doing ./configure successfully, when I type "make" I get the following error:

error 'firstErrorOccured_' was not declared in this scope.

Here is the full traceback:

make
depbase=echo RtMidi.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||';
/bin/bash ./libtool --tag=CXX --mode=compile g++ -DPACKAGE_NAME="RtMidi" -DPACKAGE_TARNAME="rtmidi" -DPACKAGE_VERSION="2.1.0" -DPACKAGE_STRING="RtMidi\ 2.1.0" -DPACKAGE_BUGREPORT="[email protected]" -DPACKAGE_URL="" -DPACKAGE="rtmidi" -DVERSION="2.1.0" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=".libs/" -DSTDC_HEADERS=1 -DHAVE_LIBASOUND=1 -DHAVE_LIBPTHREAD=1 -I. -D__LINUX_ALSA__ -O3 -Wall -Wextra -MT RtMidi.lo -MD -MP -MF $depbase.Tpo -c -o RtMidi.lo RtMidi.cpp &&
mv -f $depbase.Tpo $depbase.Plo
libtool: compile: g++ -DPACKAGE_NAME="RtMidi" -DPACKAGE_TARNAME="rtmidi" -DPACKAGE_VERSION="2.1.0" "-DPACKAGE_STRING="RtMidi 2.1.0"" -DPACKAGE_BUGREPORT="[email protected]" -DPACKAGE_URL="" -DPACKAGE="rtmidi" -DVERSION="2.1.0" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=".libs/" -DSTDC_HEADERS=1 -DHAVE_LIBASOUND=1 -DHAVE_LIBPTHREAD=1 -I. -D__LINUX_ALSA__ -O3 -Wall -Wextra -MT RtMidi.lo -MD -MP -MF .deps/RtMidi.Tpo -c RtMidi.cpp -fPIC -DPIC -o .libs/RtMidi.o
RtMidi.cpp: In member function 'void MidiApi::error(RtMidiError::Type, std::string)':
RtMidi.cpp:245:10: error: 'firstErrorOccured_' was not declared in this scope
if ( firstErrorOccured_ )
^
RtMidi.cpp:248:5: error: 'firstErrorOccured_' was not declared in this scope
firstErrorOccured_ = true;
^
make: *** [RtMidi.lo] Error 1

I have a suspicion this was due to the commit you just pushed changing firstErrorOccured to a class variable.

Assert error with Midi Output

As there isn't much information for a rusty C++ developer to use, i run into odd issues like this one...

First error happens during runtime, second happens only if i click "Continue".
Retry/Ignore leads to a "Application is not responding" message on Windows.

Screenshot: rtmidi-assert

This code is based on the MIDI Output sample code

int main()
{
    std::cout << "\n Application started\n";

    // MIDI
    RtMidiOut *midiout = 0;
    int MidiOUT;

    // RtMidiOut constructor
    try {
        midiout = new RtMidiOut();
    }
    catch (RtMidiError &error) {
        error.printMessage();
        exit(EXIT_FAILURE);
    }

    // Check outputs.
    nPorts = midiout->getPortCount();
    std::cout << "\nThere are " << nPorts << " MIDI output ports available.\n";
    for (unsigned int i = 0; i<nPorts; i++) {
        try {
            portName = midiout->getPortName(i);

            portName = midiout->getPortName(i);
            if (portName.find("Launchkey Mini") != std::string::npos)
            {
                MidiOUT = i;
            }
        }
        catch (RtMidiError &error) {
            error.printMessage();
        }
        std::cout << "  Output Port #" << i + 1 << ": " << portName << '\n';
    }
    std::cout << '\n';

    midiout->openPort(MidiOUT);

    // assert happens somewhere below
    std::vector<unsigned char> message; // To be used later
                                        // try a led
    message[0] = 153;
    message[1] = 40;
    message[2] = 54;
    midiout->sendMessage(&message);