problem transmitting some 'x...' values

[nosuchtim]

Trying to transmit 'xb06500b06400' to another instance of keykit doesn't work.

Also, transmitting 'xb065' (which is an incomplete message) ends up being received as 'xb065XX', where XX are bytes that shouldn't be included.

[pbarada]

How do I setup two keykits to talk to each other(e.g. how do I reproduce the issue on Linux)? Might turn into another test case...

[nosuchtim]

Just invoke key twice, and in one of the instances open a port for input, and in the second instance open the same port for output. In the first instance type “midimon()” in the console, and in the second instance type phrase constants (e.g. ‘a’ ) which should show up in the midimon output of the first. In the case of a note like ‘a’ you’ll see the note on and note off. The behavior of things like ‘xb064006500’ (which aren’t really sysex, they’re just using the ‘x…’ note notation) is broken. I’m traveling today so won’t be able to debug it till later. It’s likely to be Windows-specific due to the new use of rtmidi instead of portmidi, or something about running status. …Tim…

…

On Fri, Mar 24, 2023 at 4:22 AM pbarada ***@***.***> wrote: How do I setup two keykits to talk to each other(e.g. how do I reproduce the issue on Linux)? Might turn into another test case... — Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABESNSXPO4QKQ2D5OVPR5LW5V7YBANCNFSM6AAAAAAWF3RZPI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[pbarada]

Interesting.
On Ubuntu I fired up two instances (labeling them "K#" where "#" is the instance, "Shell" is a bash shell):
K1: Through Port Enabler enable "in 1" (causes ALSA to list keykit connection 128:0
K2: Through Port Enabler enable "out 1" (causes ALSA to list keykit connection 129:0
Shell: "aconnect 129:0 128:0" (to connect K2 to K1)
K1: "midimon()" (no double quotes)
K2: Type "'xb064006500'" (no double quotes)
K1 Get "'xb06400P65t43468,10'" (no double quotes)

Adding debug into mdep/linux/midi.c to dump the bytes presented to snd_midi_event_encode shows:
mdep_putnmidi:303 5
mdep_putnmidi:307 b0 64 00 65 00

Dumping the bytes received from snd_midi_event_decode shows:
mdep_getnmidi:269 3
mdep_getnmidi:273 b0 64 00

Indicating ALSA isn't properly handling running status on controller change messages correctly. I'll poke around in ALSA to see if I can understand how it handles controller messages better...

[pbarada]

Turns out the Linux/ALSA port is broken. In linux putnmidi() it calls snd_midi_event_encode and hands it the entire midi buffer (which can include multiple MIDI mesages). Digging into seq_midi_event.c, snd_midi_event_encode only encodes the first MIDI message into an event and returns. I'm working on a change to instead spoon feed the MIDI data one byte at a time to snd_midi_event_encode_byte() (which snd_midi_event_encode calls...) and when it returns a 1, call snd_seq_event_output() on the just-encoded event. Repeat over the rest of the bytes. With this change I see both controller MIDI messages showing up from midimon(). I also want to see about how to handle calls to reset the encoder periodically (since it can break running status from previous putnmidi() calls).

I have to do some more testing to make sure I'm not creating a bigger problem...

[nosuchtim]

I think internally to Keykit the intention (if I had to guess my intention from several decades ago :-) is to interpret running status on input and produce (in this example) two complete notes (or controller messages) internally. But it’s possible that’s broken. …Tim…

…

On Fri, Mar 24, 2023 at 12:46 PM pbarada ***@***.***> wrote: Interesting. On Ubuntu I fired up two instances (labeling them "K#" where "#" is the instance, "Shell" is a bash shell): K1: Through Port Enabler enable "in 1" (causes ALSA to list keykit connection 128:0 K2: Through Port Enabler enable "out 1" (causes ALSA to list keykit connection 129:0 Shell: "aconnect 129:0 128:0" (to connect K2 to K1) K1: "midimon()" (no double quotes) K2: Type "'xb064006500'" (no double quotes) K1 Get "'xb06400P65t43468,10'" (no double quotes) Adding debug into mdep/linux/midi.c to dump the bytes presented to snd_midi_event_encode shows: mdep_putnmidi:303 5 mdep_putnmidi:307 b0 64 00 65 00 while dumping the bytes received from snd_midi_event_decode shows: mdep_getnmidi:269 3 mdep_getnmidi:273 b0 64 00 Indicating ALSA isn't properly handling running status on controller change messages correctly. I'll poke around in ALSA to see if I can understand how it handles controller messages better... — Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABESNV6YZUDM26CMCK2UV3W5X22TANCNFSM6AAAAAAWF3RZPI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[nosuchtim]

Wouldn’t be surprising for rtmidi (which is newly introduced in the 64-bit Windows version) to have the same problem.

…

On Fri, Mar 24, 2023 at 1:27 PM pbarada ***@***.***> wrote: Turns out the Linux/ALSA port is broken. In linux putnmidi() it calls snd_midi_event_encode and hands it the *entire* midi buffer (which can include multiple MIDI mesages). Digging into seq_midi_event.c, snd_midi_event_encode only encodes the *first* MIDI message into an event and returns. I'm working on a change to instead spoon feed the MIDI data one byte at a time to snd_midi_event_encode_byte() (which snd_midi_event_encode calls...) and when it returns a 1, call snd_seq_event_output() on the just-encoded event. Repeat over the rest of the bytes. With this change I see both controller MIDI messages showing up from midimon(). I also want to see about how to handle calls to reset the encoder periodically (since it can break running status from previous putnmidi() calls). I have to do some more testing to make sure I'm not creating a bigger problem... — Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABESNWPM5IGM5LMN4DKQMLW5X7TTANCNFSM6AAAAAAWF3RZPI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[pbarada]

In the Linux ALSA implementation, the problem I currently see is on the encode side - as in encoding a MIDI stream to ALSA sequencer events. With my tweaks (thus far), if I send 'xb064006500' from one keykit instance, midimon() on the the other instance produces:
'xb06400P65t16037.10'
'xb06500P65t16037.10'

which I believe is expected.
My concern is if I don't "reset" the stream then running status can be go for quite a while - what I think would make sense is to have a "reset running status" variable that causes the output side to reset tracking of running status - rather than assuming receiver can track running status forever. Issue is mdep_putnmidi() is (probably?) too low a level to force the running status reset (need to dig deeper to know for sure).
I'll do some testing over weekend and create another pull request for the ALSA chances. Any idea if there are people using keykit w/ALSA that can beat on it?

Next step (after fixing this) is to implement some type of copy/log for console so its simpler to capture the console output (figure a menu item to burn the console scroll content to a file) since copy/paste on various targets is tedious at best.

[pbarada]

With my above changes (so far), if I split the controller message stream into 'xb064' then '00' midimon() in the other instance finally shows the full controller event 'xb06500P65Txxx,10', so looks like I'm on the right path(ALSA wise)...

[pbarada]

Tim, See b3ad39e for base changes to fix ALSA MIDI output (and handle your 'xb064006500' test on Ubuntu).  This isn't complete, still need to better understand context snd_midi_event_reset_encode is needed; figure it should be done periodically, but only when know when a MIDI output buffer _has_ a starting MIDI status.

On 3/24/23 16:36, Tim Thompson wrote: Wouldn’t be surprising for rtmidi (which is newly introduced in the 64-bit Windows version) to have the same problem. On Fri, Mar 24, 2023 at 1:27 PM pbarada ***@***.***> wrote: > Turns out the Linux/ALSA port is broken. In linux putnmidi() it calls > snd_midi_event_encode and hands it the *entire* midi buffer (which can > include multiple MIDI mesages). Digging into seq_midi_event.c, > snd_midi_event_encode only encodes the *first* MIDI message into an event > and returns. I'm working on a change to instead spoon feed the MIDI data > one byte at a time to snd_midi_event_encode_byte() (which > snd_midi_event_encode calls...) and when it returns a 1, call > snd_seq_event_output() on the just-encoded event. Repeat over the rest of > the bytes. With this change I see both controller MIDI messages showing up > from midimon(). I also want to see about how to handle calls to reset the > encoder periodically (since it can break running status from previous > putnmidi() calls). > > I have to do some more testing to make sure I'm not creating a bigger > problem... > > — > Reply to this email directly, view it on GitHub > <#13 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AABESNWPM5IGM5LMN4DKQMLW5X7TTANCNFSM6AAAAAAWF3RZPI> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMXGS2YIWOUWMDEQ5M22LTW5YATLANCNFSM6AAAAAAWF3RZPI>. You are receiving this because you commented.Message ID: ***@***.***>

-- Peter Barada ***@***.***