MIDI control output queue events

[igorangst]

I am observing strange behavior at the MIDI control output for queued events, both using ALSA and Jack (Linux, compile version 0.98.10).

I have configured events for my controller as follows (example for pattern 1):

0 [ 0x90 36 127 ] [ 0x80 36 127 ] [ 0x90 36 63 ] [ 0x80 36 0 ]

So I want to see a "note on 127" for arming, "note off 127" for muting, "note on 63" for queuing, and "note off 0" for deleting a pattern. Without the queue modifier, everything works as expected, "note on 127" for arming, "note off 127" for muting. Once I activate the queue modifier, this is what I see:

• If the pattern is currently muted and I (queue to) arm it, I get a mute event immediately ("note off 127") and no other event when it is effectively armed
• If the pattern is currently armed and I (queue to) mute it, I get an arm event ("note on 127") immediately and no other event when it is effectively muted after the end of the pattern

I never observe a queue event. What is the expected behavior here?

[ahlstromcj]

Thanks for the report. Will try it out soon!

[ahlstromcj]

I fixed a few aspects of displaying the playing, queuing, muted, and removed/empty/deleted status, and so one should see this when patterns are present and playing:

 Empty slot: dark
 Muted slot: red
 Playing slot: green
 Queued slot: amber (this means the slot is queued to turn on)
 Unqueued slot: amber (this means the slot is queued to turn off)

Took me awhile to find out the places to do these announcings, but it fixed a lot of display issues. Let me know of any more you find. Thanks!

Also fixed some minor irregularities with handling the 'ctrl' file.

Checked into the portfix branch. I still need to do testing while following up on the issue of virtual ports and MIDI control.

[igorangst]

Hi, thanks for looking into this issue. I tested the latest commit in the portfix branch. Here is what I see with both Jack and ALSA:

• When stopped, the correct events occur (arm, mute, queue). However, there are two identical messages per event. This is not the case for modifier buttons (for example queue modifier on only sends only one message)
• When I push the start button, the control output goes wild: It loops over all the patterns and constantly dumps their status to the control output bus. My monitoring app (qmidiroute) even crashed in face of the message overload.

I suppose you do the "printing" at the same time as the screen updates? I think it should only happen when there is a state change.

[ahlstromcj]

Odd. I have seen double notes on one of my systems. Can't remember if it were JACK or ALSA, but it didn't occur on the other. However, in this case, I will bet it is a side-effect of my latest fix; I had to insert the relevant code in a couple different places to cover the various ways the pattern status could change.

I didn't (I hope) tie MIDI display updates to the GUI, since I also support a command-line version of Seq66. I try to load all kinds of work into the performer class, to centralize things.

I will have to check again on JACK to see about the wild output. Doesn't seem to happen on ALSA. Thanks for the tip on qmidiroute, didn't realize it could be used for monitoring (actually did not know it existed :-D). Thanks! Cannot get to it right away, but by tomorrow for sure.

-- Q: Why did the astrophysicist order three hamburgers? A: Because he was hungry.

[ahlstromcj]

Can't really see a barrage of events if I route the display output to Qsynth. Couldn't get qmidiroute to show anything at all, must try harder. Anyway, one thing to double check is that you don't have a MIDI thru loop working. I've blasted a Yamaha keyboard that way before. Will keep looking.

[ahlstromcj]

I verified the double notes again. I want to check it out on the other laptop to see if it happens there too.

I also verified the too-frequent sending of Launchpad display message. Wasn't a wild amount, but should not happen, will track it down.

I ended up using aseqdump and manual/virtual ports on Seq66 to verify this issue in ALSA.

• When stopped, the correct events occur (arm, mute, queue). However, there are two identical messages per event. This is not the case for modifier buttons (for example queue modifier on only sends only one message)
• When I push the start button, the control output goes wild: It loops over all the patterns and constantly dumps their status to the control output bus. My monitoring app (qmidiroute) even crashed in face of the message overload.

[ahlstromcj]

I think I have this working well in the portfix branch. Had to probe around quite a bit to find just where to put the announce_pattern() calls. Tested with virtual ports and aseqdump --port=129:4 (for example). Also seems to work with queuing/unqueuing.

[igorangst]

Great. I just compiled and tested with ALSA virtual ports. I confirm the double messages are gone, and no more looping when play is on. There is only one small quirk left it seems:

• When the sequence is muted, queueing works like a charm and the correct arm message is sent when the sequence is actually activated
• The other way round (unqueueing) gives me one queue event when I dequeue (this is correct) and another queue event when the sequence actually goes mute

[ahlstromcj]

Interesting! Will look more closely tomorrow morning. You never know when a hidden issue will be unearthed.

• The other way round (unqueueing) gives me one queue event when I dequeue (this is correct) and another queue event when the sequence actually goes mute

[igorangst]

Tested again the latest commit with Jack. Queuing and dequeuing works now as expected.

[igorangst]

Works also with ALSA virtual ports.

However, I also observed that when pressing the "stop" button in the GUI, there is a pair of messages for each armed pattern on the output bus: a mute message, followed by an arm message. Repeatedly pressing the button produces these messages each time. Is this expected?

Otherwise, this issue can be closed.

[ahlstromcj]

I have recently (0.99.3) made a number of updates to MIDI control (though will probably rush to 0.99.4 soon). For now I will close this one, but feel free to reopen it or log a new issue if necessary. Thanks!