void Tracks::adjust(int numMCUChannels) {...} in Tracks.cpp causes serious performance problems with Reaper's mixer

[Christopher Norman]

Hi there,

After some months of attempting to track down poor mixer performance in Reaper, I've narrowed it down the the forementioned function in the MCU plugin. Under perfectly normal mixing conditions, this function is consuming, on my system, ~30% of Reaper's total CPU load and causing Reaper's mixer to render at unacceptably low refresh rates. This occurs even if no control surface is connected, so merely by loading the MCU plugin.

Adding an immediate return to this function (obviously breaking MCU functionality in the process) solves the refresh rate issues in Reaper.

Secondly, although this might be a red herring from the profiler, when the MCU is disconnected the call to UpdateGlobalSoloLED() in void CSurf_MCU::Run() {…} appears to be consuming excessive CPU cycles (~10% of total), although I have a suspicion this may be resolved by fixing the above.

Best regards,

CJPN

Edit: See https://forum.cockos.com/showthread.php?p=2644161

[Steffen Fuerst]

Thank you for your report (and the other issues).I'm pretty busy right now, but in two weeks I'll have plenty of time thanks to a vacation and will take a closer look at it all then.

[Christopher Norman]

No probs! Further research has narrowed it down to the code snipped below. Given that the “Show in TCP” checks are performed continuously, thus we don’t risk losing some critical change of sate, might I suggest returning from the function immediately prior to the updateTCP section unless some sensible (33ms for 30Hz?) time has passed?

  void Tracks::adjust(int numMCUChannels) {

  ... ... ... ...

    bool updateTCP = false;
    //CJPN - Commenting out the following mitigates Reaper mixer performance issues
    // adjust TCP
    if (m_pOptions2->isOptionSetTo(MTO2_TCP_ADJUCT, MTO2A_TCP_BANK) ||
        m_pOptions2->isOptionSetTo(MTO2_TCP_ADJUCT, MTO2A_TCP_SELECTED)) {
        BOOST_FOREACH (tTrackStates::value_type &v, m_trackStates) {
        TrackState *pTS = v.second;

        bool *pShowInTCP = (bool *)GetSetMediaTrackInfo(pTS->getMediaTrack(),
                                                        "B_SHOWINTCP", NULL);
        if (m_pOptions2->isOptionSetTo(MTO2_TCP_ADJUCT, MTO2A_TCP_BANK) &&
                (*pShowInTCP != pTS->isOnMCU()) ||
            m_pOptions2->isOptionSetTo(MTO2_TCP_ADJUCT, MTO2A_TCP_SELECTED) &&
                (*pShowInTCP != (m_selectedTracks.find(pTS->getMediaTrack()) !=
                                m_selectedTracks.end()))) {
          updateTCP = true;
          break;
        }
      }
    }
    //CJPN end of problem

  ... ... ...

}

‌

[Steffen Fuerst]

Just a small update: Due to a bereavement in the family, I did not have time to look at your reported issues during my vacation. But I still have them on the radar and hope next week then finally really work on it.

[Steffen Fuerst]

I have now looked at this, but I cannot reproduce the problem. My first suspicion was that for some reason updateTCP is always set to true at the point shown, because then further down regularly

TrackList_AdjustWindows(true);
UpdateTimeline();

which would explain your observation very well. But this is not the case. Everything works as expected (besides the bug that I only set the B_SHOWINTCP state when bShowis true, which will be fixed in the next release).

Can you maybe set updateTCPalways to false instead of commenting out the shown place? Or set a breakpoint in the UpdateTimeline() line and check that this is not reached twice without navigating with the Mackie control?

[Steffen Fuerst]

need further input