Continous stream of midi feedback when automation read/preview, even if stopped

[Fred]

Hi,

thanks for this gem of software. I was able to build my dream setup with it. But now an obstacle separates me from musicmaker’s paradise:

Curent behavior:

A flood of midi feedback is continuosly sent to the controller. This happens when the host is:

• stopped
• playing, and envelope value is constant

For each parameter, Realearn currently sends what looks like ~10 midi messages/second. Few parameters are enough to make the host stutter, even when stopped. I can only give up either automation or feedback.

Happens with:

Targets: Track Send volumes / NI transient master (x64) / FabFilter Pro-Q3 (both Vst2 or Vst3) / FabFilter Simplon

Envelope: Active (Armed or not)

Automation Mode: Read or LatchPreview

Playback: play or stopped

Midi Feedback: on

Expected behavior:

Midi feedback is sent only when a change in value happens (as it’s already the case for most of the paramteres).

Screenshots:

‌

‌

‌

I wish I could help, but c++ is way out of reach.

‌

‌

[Benjamin Klum]

Hi Fred. I’ll see what I can do. I’ll try to let ReaLearn send feedback only if a parameter value has changed - which is normally the case, but seemingly not when automation is used. I’m not sure though if the “sending MIDI to hardware device” part really causes the performance issues. It might as well be the logic that happens before sending the MIDI. When you say that the host stutters, do you mean the GUI?

[Fred]

Hi Benjamin, thanks for your time. While doing some tests I began to suspect that the problem might be in my setup. I’d keep this on hold until I am 100% sure the problem persists. Will give you feedback in the next days.

[Benjamin Klum]

Hi Fred. Could you try the latest pre-release? I didn’t specifically look into your issue, but chances are the behavior changed because the new ReaLearn is a complete rewrite - so testing with the old version doesn’t make much sense.

The latest pre-release is available via ReaPack by importing this repository: https://github.com/helgoboss/reaper-packages/raw/master/index.xml. Please note: There are still some issues with installing ReaLearn that way if you use both 32-bit and 64-bit REAPER. Let me know if that’s the case.

I’ve quickly tried your project with the new ReaLearn but I didn’t find anything weird so far. But then … it might be related to the fact that I don’t have your controller.

[Fred]

Hi Benjamin,

I thought I deleted the attachment (I was still in the process of commenting it, my bad).

I tested the new plugin from Reapack, but the problem is still there. I did some deeper tests:

• it doesn't depend on the controller. I turned it off and used a virtual midi channel (LoopMidi) as the "MIDI Feedback Output" and monitored the messages with MidiOx.
• it happens with every plugin (VST2,VST3,JSFX) and send volumes, and not just for some as I was thinking before.
• it happens with every automation mode (latch, touch, read, ...), except for ‘write'. It makes me think that Reaper is in control, constantly updating the values of the parameters - even if the value is the same or the playback is stopped. Probably it’s the way Reaper makes parameters 'stick' to automation value when the user tries to change them manually.
• CPU usage doesn't increase noticeably.
• the more the mapped parameters, the more the feedback messages per second, the more the GUI stutters. Disabling feedback ends the stuttering (with some delay, see below).
• the more the mapped parameters, the more the audio clicks. Disabling feedback stops audio from clicking.
• the most problematic part: when I disable the feedback, messages keep arriving for some time until the 'buffer' is empty. The feedback is delayed. With the attached test file (just 20 mapped params) turning on feedback for 30 seconds and then off again will send feedback messages for additional ~40 seconds, even when the playback is stopped. Increasing the time or the number of mapped parameters, the 'tail' of midi messages can last minutes. When the controller is connected, the knobs keeps moving until the buffer is discharged.
• for the reason above, in play/record mode the feedback gets increasly behind the current automation value.
• when using my hardware controller (bcr2000), the higher the feedback troughput, the more the controller's knobs jumps, instead of following automation curves smoothly.

I can't understand whether the bottleneck is just the high midi throughput of the feedback or the business logic behind it. I assume that so many midi messages are themselves a problem at a certain scale.

I wish it would be just as simple as reducing feedback only to the parameters that actually changed value, regardless of the host sending automation updates.

I attached an updated version of the test project with the latest Realearn. I am ready to perform further tests if needed.

[Fred]

test with the latest version

[Benjamin Klum]

Hi Fred, thanks for all the detailed info (finally some feedback about the new version, too). I want to look into it today. I assume you use REAPER 64-bit? If you have the possibility for some more direct communication (message, call, screen sharing), that could come in handy with this kind of problem. If you are up to it, contact me on [e-mail]. But for now I’m trying to understand and reproduce your problem without that.

[Benjamin Klum]

I see the problem. Could reproduce it. Working on it.

[Benjamin Klum]

This “continuous feedback even without value changes” happens when automating FX parameters, send volume and send pan. REAPER fires no matter if there’s a value change or not. Actually also with other parameters (track volume, track pan), but in those cases ReaLearn already applies a filter. I will apply the same kind of filter to the other targets as well.

[Benjamin Klum]

Please try with pre4. Let me know what it fixes for you and what not.

I fixed a number of issues including hopefully yours, the one where REAPER continuously sends notifications even the value didn’t actually change (for FX param values, send pan and send volume). It’s still possible that ReaLearn sends more feedback than necessary when having automation. This can happen if there ARE value changes, but they are so small that they don’t have any effect on the feedback MIDI value (because MIDI feedback values have a very low resolution). I think this can be improved too.

Oh, and I also included the option to send feedback to <FX output> so instead of using MIDI-OX you could just insert a ReaControlMIDI behind ReaLearn and check feedback.

[Fred]

Hi Benjamin,

I confirm that issue is solved!

Some very good notes about pre4:

• The project load extremely faster (I have a project with 98 Realearn instances (yep). It was taking around 10 minutes to load, now few seconds! Awesome!)
• The project runs extremely smoother (Selecting a track with ~50 mapped params took ~4 seconds, now it’s instantaneous. Wonderful!)

Unfortunately, there are a couple of issues that make it still unusable, I will address them in separate tickets.

‌

‌