Bug? ReaControlMIDI not sending chased events during playback

I just automated the Mod Wheel with ReaControlMIDI. In one section the value is 127, in another it's 0. If I click the play cursor into each section: - when playback is stopped, the value is chased correctly on the TCP, and sent out correctly by ReaConntrolMIDI: - but during playback, the value is still chased on the TCP but is NOT sent out by ReaControlMIDI! : Anybody else seeing this? Settings: (midi_eater just filters out messages like PolyAT to keep the log clean, the 2nd ReaControlMIDI is just used to log).

Please wait for some feedback before you submit a bug to the tracker. I can't reproduce this, CC is being sent regardless of transport state. Could you provide a step-by-step recipe to reproduce the problem as described here please? A minimal project (also without any 3rd-party plug-ins) to reproduce the problem could help, too. Maybe a screenshot of your seeking settings in Preferences has a clue?

I did wait a few days but it keeps biting me in the ass. I'm a programmer myself, it's 100% reproducible here, across different tracks and CC#s. Bear with me, I'll get you a sample project and full details in the next 24 hours. And here's the screenshot of my seeking prefs: (Reaper 4.402 x64, Windows 8-64 Pro)

(Reaper 4.402 x64 on Win 8-64 Pro) Sample project attached. It's the same track shown in the screengrabs above. Following the original example: (using the 2nd instance of ReaControlMIDI as a MIDI monitor): - With playback stopped, click the play cursor in the area with the 0 automation value. Then click into the 127 area. The TCP value updates correctly., and Rea correctly sends matching Mod wheel events. - now start playback, and do the same. The TCP value still updates, but Rea does NOT send matching wheel updates! - now stop playback, try again (Rea again sends values correctly).

I tested the project with v4.402 x32 WinXP Pro. When the project was stopped, the changed Modwheel values were shown correctly by the TCP and the ReaControlMIDI fader, but not shown in the sending ReaControlMIDI log, nor in the receiving ReaControlMIDI monitor instance. When new envelope points were added, same thing. When I bypassed the JS MIDI/midi_eater, the receiving ReaControlMIDI showed all the changes, all the time. The sending ReaControlMIDI acted just like previously of course. No difference when playing the project.

Can't test more today but I'm getting different results (on OSX) than xpander: - midi_eater is doing its job and eats all MIDI including the messages from the first RCM instance - on playback the seek messages are not in the log indeed but I have a feeling that they're just dropped in the massive flood of incoming aftertouch messages because... - ...when I delete or move the MIDI item, the messages are being logged on stop and playback as expected. Edit: checked with a synth at the end of a chain, the wheel messages are not only being dropped in the log. Since xpander is getting different results I tend to think that's a processing/thread priority/along these lines thing caused by the massive amount of data.

Thanks for checking it out guys. Not sure about xpander's result (32/64bit difference?). . Ollie, I don't think it's internal message overload: - I tested with midi_eater in the first slot, to avoid RCM getting flooded. Same result so that's not it. - It's unlikely to be engine flooding. If the slow MIDI interface can send the PAT stream and Reaper can record it & plays it back fine, there should be no issue (unless there's a bug somewhere). - even when it fails, it will send out new values once they actually change in the automation (ie. on the ramps). (that's also why the issue is easily missed unless you do on/off style automation where the value doesn't change for a long time - my projects are full of those). . So it seems like something else is going on, most likely some bug in RCM related to playback seeking. . Note I also just tried with values other than 0/127 (to discount those values triggering the bug), same result.

- To test your theory, I deleted all PAT messages in the MIDI Event list. Same result (even with midi_eater disabled). So it's not PAT overload. - if there are ONLY notes (no other messages at all), it still fails. - if I delete ONLY the Notes, it works! Also (as you said) if the MIDI track is removed completely. . So the bug could be related to note chasing when seeking.

I just tried x86 Reaper, I see exactly the same behaviour (same bug) as on x64. And I can't repro anything xpander is seeing - weird.

OK, now I understand the confusionn - my version of eater has plenty of sliders (screenshot attached)! I can see that the versions in: Code: