Better rawMIDI parser and support for Virtual RawMIDI port

[patriciogonzalezvivo]

Context for this PR is in this thread: https://llllllll.co/t/opening-midi-port-from-external-c-program-using-rtmidi/36456/34

This PR introduce:

• Virtual RawMIDI initialization. This is mostly useful devices where you have access through ssh and you are willing to send MIDI events to matron from other programs like aplaymidi, midigyver, rtpmidi, ravelox, etc or bluetooth (which still require the recompilation of bluez as I understand).

• Reimplement the MIDI parser. Why? non-USB midi devices don't constrain into the 3 bytes packages for CC and NOTE_ON, NOTE_OFF, etc. For example they don't send the event type if is the same of the previous. Also they will pack as much events in a single call. This made the previous implementation not flexible enough for non-usb midi devices. With this PR that's solve that and open the doors for better MIDI support. Much of this re-implementation use FluidSynth code taken from here: https://github.com/FluidSynth/fluidsynth/blob/master/src/drivers/fluid_alsa.c

I test this with a physical device: NanoKONTROL2 and through software through aplaymidi

[ngwese]

I haven't looked into the PR in detail but we should be aware of any documentation/reporting requirements needed as part of the license requirements attached to the code from FluidSynth.

[patriciogonzalezvivo]

@ngwese seams like the licenses are compatible but I'm not an specialist on that

[patriciogonzalezvivo]

I can confirm it works connecting with through RTPMIDI to iPad/MacOS and other devices with rtpMIDI supprt like linux:

[~]$ aconnect 128:2 129:0 
[~]$ aconnect -l         
client 0: 'System' [type=kernel]
    0 'Timer           '
    1 'Announce        '
client 14: 'Midi Through' [type=kernel]
    0 'Midi Through Port-0'
client 128: 'rtpmidi norns' [type=user,pid=366]
    0 'Network         '
    1 'razor           '
    2 'Patricio’s DrawingPad'
        Connecting To: 129:0
client 129: 'Client-129' [type=user,pid=18396]
    0 'Virtual RawMIDI '
        Connected From: 128:2

or

[ngwese]

One final request is to squash down the commit history into a single commit so that it is easier to track this as an atomic change (should problems arise later).

After the above comments are addressed I'm excited to test this on my hardware which sees a lot of MIDI traffic. Ultimately @artfwo and @catfact should probably take a peek as well.

[ngwese]

Suggest checking for allocation errors.

[patriciogonzalezvivo]

Haven't seen other checks for allocation errors in matron do you mind pointing out what would the optimal way to do it in norns ecosystem?

[ngwese]

I am not a licensing expert but I do not believe the above link is sufficient attribution. It is not uncommon for projects to contain code which is licensed under multiple different licenses. The concerns I have are:

• The inline link in the code does not reference a specific file in the upstream project
• The link in the PR which does point at a file, does not appear to point to the file which contains the fluidsynth midi parser (which I'm guessing is the bulk of the adapted code)

The provenance of the adapted code would be clearly established if:

• The code was isolated in its own file and not mixed with existing source
• The code carried the copyright and license text of the original file
• The code include references to the original file(s)
• The code; if heavily altered, should briefly explains what was altered

In reading through the LGPL 2.1 text (again I am not an expert) I am lead to believe this PR does not comply with the LGPL 2.1 terms, specifically:

2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

a) The modified work must itself be a software library.
b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change.
c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License.
d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful.
(For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application.
Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.)

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

Reading further; section 3 of the LGPL, states that in cases where part of an LGPL library are incorporated into a program:

3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices.

While the above does seem to indicate LGPL code can be incorporated into this GPL3 code base the expectation remains that the licensing notices in the original files are carried over and updated accordingly.

[artfwo]

the entire parser could be moved to its own file too. why is this parser necessary again? can you describe a use-case supporting the idea for providing non-usb device compatibility requirement (as norns only has usb ports).

[patriciogonzalezvivo]

@ngwese I just add a better breakdown of where the repurposed FluidSynth functions came from. Need to add the FluidSynth CopyRights to it. Could you point to examples I can follow?

@artfwo I'm new to the community but looking around on the forum and other past issues and PRs there seams to be other attempts to have better support for non-usb MIDI drivers, like bluetooth and gpio. I understand that those cases deviate from the original hardware. Also I understand that having a "Virtual RawMIDI" port is only useful if you are going to link something to it. Selfishly this means I can connect other programs external to Norns/Matron ecosystem to that MIDI port and capture those events from any Norns script that listen to the MIDI port.

The most exciting use case I found after installing RTPMIDI. This allows MIDI over network following this protocol compatible with iOS/OSX devices. There is no need for bluetooth. Right now, with the code as is, this require some wiring through a ssh session:

1. First to install RTPMIDI

wget https://github.com/davidmoreno/rtpmidid/releases/download/v20.07/rtpmidid_20.07_armhf.deb
sudo dpkg -i rtpmidid_20.07_armhf.deb

2. Make sure your iOS/OSX device is sending MIDI events to Network
3. Check that you can "see" the device from Norns. In this example I can see booth my linux laptop (razor) and my iPad (pilot)

[~]$ aconnect -lio
client 0: 'System' [type=kernel]
    0 'Timer           '
    1 'Announce        '
client 14: 'Midi Through' [type=kernel]
    0 'Midi Through Port-0'
client 128: 'rtpmidi norns' [type=user,pid=350]
    0 'Network         '
    1 'razor           '
    2 'pilot           '
client 129: 'Client-129' [type=user,pid=28138]
    0 'Virtual RawMIDI '

4. Link the out put of the RTPMIDI client to the "Virtual RawMIDI" so it can be read by any norns script:

aconnect 128:2 129:0

I think in furthers PRs and through collaboration, we could work on simplifying this process through the nice UI Norns have : )

[patriciogonzalezvivo]

Also curious if there is a chance to have the RTPMIDI package already pre install... or installed through and update

[tehn]

we could certainly bundle this into the next update if people are interested

[artfwo]

the entire parser could be moved to its own file too. why is this parser necessary again? can you describe a use-case supporting the idea for providing non-usb device compatibility requirement (as norns only has usb ports).

[patriciogonzalezvivo]

Collapsing the PR into a single commit here #1204
and closing this one.
Sorry