basshelal / jrtmidi

Java bindings to RtMidi using JNR written in Kotlin

Bassam Helal

jrtmidi's Issues

Create an example repository

Create an example GitHub repository using the library as if it is in a project, using both Java and Kotlin to demonstrate how to use it.

A simple use case can be a Midi through client, ie, sending messages from one readable port through to another writable port which we can also listen to to ensure that the messages are received.

RtMidi native library floods output console when internal message queue limit is reached

If a ReadableMidiPort receives enough messages to fill its internal (RtMidi) queue (100 by default in RtMidi and also 100 in JRtMidi, ReadableMidiPort.DEFAULT_QUEUE_SIZE_LIMIT) then our console gets flooded with error messages saying MidiInAlsa: message queue limit reached!!.

Setting the queue size to 0 causes a segfault later and setting it to a large number actually allocates all that memory only for it to inevitably flood the console again once that limit is reached anyway.

I have already filed an issue with RtMidi about this here: thestk/rtmidi#236

But most likely, we will have to figure this out for ourselves by probably trying to suppress the output somehow.

I know this is somewhat of a minor nitpick, but the way I see it, the native library should only be printing to the console if we let it, ie some kind of debug flag in RtMidi.Config, otherwise, a Java application should only be seeing Java output on its console.

It's actually more annoying because it happens upon every new received message, so in some cases, "flooding" is actually an understatement, not good, especially for development and debugging, but also for production too, since a GUI-less application will also be flooded with this as well.

Publish `1.0-alpha` release to Maven Central

When all is fully tested to be working on all platforms, we should publish a 1.0-alpha release to Maven Central.

This release should include with it the native shared libraries of RtMidi so consumers use bundled libraries, so before we can do that we need to ensure that basshelal/RtMidi-Builds#3 is met, so that we have verified and lean libraries that will be used by consumers of the supported platforms.

The release is alpha because I need to ensure it's usable (and works well) by clients through Maven Central, basically mimicking a real life scenario. This will be done by doing an example project that pulls from Maven Central, see #1

If that works well (which it probably should), then we can go for a full fat 1.0