thestk / rtmidi Goto Github PK
View Code? Open in Web Editor NEWA 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)
License: Other
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)
License: Other
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.
I'll update this with details in the next day
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
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.
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
Line 1275 in edb963b
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.
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
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?
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
I tried u sing isPortOpen with virtual ports and they always seem to return false, is that normal ?
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?
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?
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?
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".
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
looks like the link to the docs is broken in the current README.md, pointing to a doc/html dir that does not exist.
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
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.
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?
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;
}
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?
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?
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
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?
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
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.
I found a solution for linking issues under VS2015.1. Dont forget to compile against v140_xp.
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.
couple Makefile.in fixes for a cleaner build on linux
install
to create missing directories - e.g. fakerootmake install
- https://www.gnu.org/prep/standards/html_node/DESTDIR.htmlMy 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);
};
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
Since the API change (particulary in this commit 2c7a666), would it be possible to release a new version?
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 .
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
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.
Also: thestk/rtaudio#62
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.
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
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 ?
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);
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.
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
deleting RtError.h from Makefile.in precludes failure of make
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
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.
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
?
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?
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?
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.
Hi,
Everything I send thru a MIDI out virtual port is received on the MIDI in virtual port. Is is normal?
Thx,
Nuno
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 .
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.