Combination lag using MIDI signals

[davy7125]

I discovered on a Raspberry Pi a weird behavior.
To describe the issue I made a minimal disposition comprising:

• around 60 stops
• a combination "tutti", enabling all stops
• a combination "global cancel", disabling all stops

bug gc-tutti lag.zip

If I click on the combination "tutti" with the mouse, all stops are enabled instantly.
But when I link this combination to a MIDI signal that activates it, we are able to see that the stops are not enabled instantly. This is still fast, but with a heavier disposition this can impair the sound (stops are progressively enabled and the effect is not very nice when playing).

I tried to synchronize an activator to the combination, the activator being linked to a MIDI signal, but same problem.
This is like the signals or not processed the same way if we click or if we use a external MIDI signal.

[svenmeier]

Mouse operation or activation by MIDI signal should not make any difference. Internally it's handled identically.

I don't have a Raspberry at hand for the next two weeks - is this platform dependent or can this problem be replicated on a Linux PC?

[davy7125]

I confirm the behavior is the same using my Fedora, though less problematic since the hardware allow faster operations. You should be able to see the difference between a mouse click and a MIDI signal without a Raspberry.

[svenmeier]

There's a small difference depending on how you initiate a combination:

When initiated via mouse, all stops are activated on the GUI-thread. This forces the repainting of the GUI to be is deferred until all stops have changed.

When initiated via a MIDI signal (i.e. on the MIDI thread), the GUI can repaint all stops synchronously.
This might lead to several smaller GUI updates, depending on the position of the stops some areas might even be drawn several times - this happens when the GUI system decides to combine drawing areas into larger areas :(.

But as far as I can see, this is a graphical problem only: the time to activate the stops should be the same. Either way, the graphic updates do not hinder the MIDI processing.

[davy7125]

I made further tests and you are right: the lag impairs only the GUI and not the sound. I close this issue, sorry for that.

[davy7125]

I'm reopening this bug after further investigations. I am using a disposition comprising more mechanics such as a stop counter and the difference between a mouse action and an external MIDI action is more pronounced. Using a MIDI signal, the stops are not called / removed at the same time:

• graphically we can see that the stops are called / removed progressively,
• we can hear it (see below),
• the LEDs on the MIDI console are also progressively on / off.

What is quite bad is the impact on the sound and in this archive you will find two MP3:

• a first one calling all stops and canceling everything using the mouse (OK),
• a second one using an external MIDI signal instead (KO).

Context: disposition with 64 stops on a Raspberry Pi.