Ok. Good news new approach works just like the previous one: only pops the first one. Still is nice that is not necessary to load the 4*16 virtual raw MIDI ports that the kernel loads… norms will load just one “Virtual RawMIDI” port.
Regarding the mystery of “just-the-first-event” I sit to do more test and seams we are losing data or the buffer get shifted or something:
Here is what I get:
When I send to CC events
- Key
12 with value 34
- Key
23 with value 45
but what arrives is only one CC event to key 34 with value 23 !!!
It’s like it lost some bits on the way or they got mixed up.
Any suggestion??
This is what the MidiGyver script looks like:
1 out:
2 - midi://Client*:6
3
4 pulse:
5 - name: main_loop
6 bpm: 60
7 shape: |
8 function() {
9 return {
10 'Client*': [[12, 34] , [23, 45]]
11 };
12 }
And this is how MidiGyver construct their messages: https://github.com/patriciogonzalezvivo/MidiGyver/blob/master/src/MidiDevice.cpp#L95-L106
More context if create another port with amidi and dump the content of it I get this:
[~]$ amidi -p virtual -d
B5 0C 22
17 2D
0C 22
17 2D
0C 22
17 2D
0C 22
17 2D
0C 22
17 2D
0C 22
17 2D
0C 22
17 2D
0C 22
17 2D
0C 22
17 2D
0C 22
17 2D
0C 22
17 2D
...
Do this looks ok??
Mmmm… replaying my own question seams I’m missing the header of the event’s except the first one:
Here is the dump of a “real” device.
...
IO hw:2,0,0 nanoKONTROL2 MIDI 1
[~]$ amidi -p hw:2,0,0 -d
B0 40 7F
B0 40 00
B0 40 7F
B0 40 00
B0 30 7F
B0 30 00
B0 20 7F
B0 20 00
B0 41 7F
B0 41 00
B0 31 7F
B0 31 00
B0 21 7F
B0 21 00
B0 42 7F
B0 42 00
B0 32 7F
B0 32 00
B0 22 7F
B0 22 00
B0 43 7F
B0 43 00
B0 33 7F
B0 33 00
B0 23 7F
B0 23 00
...
Ok, I try sending events thorugh aplaymidi this is what it arrives to matron
And this is what it should look like
[11/11]
[~]$ amidi -p virtual -d
B0 07 64
90 3A 5A
C1 18
B1 07 64
C1 18
91 3A 5A
90 3A 00
39 5A
91 3A 00
39 5A
90 39 00
3A 5A
91 39 00
3A 5A
90 3A 00
3C 5A
91 3A 00
3C 5A
90 3C 00
3A 5A
91 3C 00
3A 5A
90 3A 00
91 3A 00
90 3A 5A
91 3A 5A
90 3A 00
39 5A
91 3A 00
39 5A
90 39 00
3A 5A
91 39 00
3A 5A
90 3A 00
3C 5A
91 3A 00
3C 5A
90 3C 00
3A 5A
91 3C 00
3A 5A
90 3A 00
91 3A 00
Note that the change is on the pitch not the velocity, and matron it’s getting only the note_on messages not the note_off. Consistently with what I see with midigyver only seams to log when there is a change of channel.
