GUI refresh and redraw very slow

[srdmusic]

Happy Holidays everyone!

Has anyone been experiencing slow track selection/ arming or really slow scrolling with Reaper lately?

I’m not sure if it’s just that my template is getting larger or if it's the latest versions of Reaper getting slower but the GUI is very sluggish now.

I have a very powerful workstation GPU (Nvidia Quadro M400) so I doubt is a question of GPU performance. The PC is a 24 core, 128GB RAM server so I'm assuming it's also not an issue with CPU power.

When I select multiple tracks that are ‘Automatic Record armed’, it takes about 2-3 seconds before it actually arms the tracks. If I try to select something like 100 tracks, Reaper basically freezes/crashes. I believe this is due to Reaper switching the track from anticipatory fx to live mode.

The problem is exacerbated if I have the mixer and the TCP open at the same time. I believe this is due to the MCP scrolling to the selected tracks.

I also have very slow GUI redraw when switching tracks with the FX window open. This may be due to something slow with the way Kontakt or omnisphere draws it’s images on the screen but it seems to be getting progressively worse lately.

I'm also seeing very sluggish scrolling through tracks with the mouse wheel. It's also extremely slow if I'm marquee selecting items that require the screen to scroll. If I use the scroll board on the right side of the screen, Reaper scrolls just fine. So it's almost like the action of scrolling with the mouse wheel or selecting items is causing something with the GUI to really slow down.

Regardless, all of these sluggish GUI redraws are really slowing my workflow down I never seemed to have this sort of problem in Cubase on the same rig.

Thanks in advance for your advice.

Specs

Windows: 10 Creator Edition Latest Version updated yesterday
Reaper: 5.70 Latest version available
Ram: 128GB
Drives: 14x 500GB Raided SSD Drives
CPU 24 core Intel E5 Processors (48 cores with hyperthreading on)
GPU: Nvidia Quadro M4000

[heda]

REAPER has always been slow arming tracks.
I never recommend using the autoarm feature, because it can get really slow if many tracks are selected. Or if you have a custom action that uses "select all tracks" to do something for example, and you have 1000 auto armed tracks, it can be extremely slow.
Other issues you mention such scrolling, I don't see it. But I may not have as many tracks.

[srdmusic]

I agree. It's extremely slow arming tracks with Auto Record turned on. Is there a preference that would make that process faster? Like turning off anticipatory fx or media buffering on selected tracks?

What's your work around for quickly arming a track that you've selected? I don't want to have to use an action to arm a track when I select it.

I currently have a custom action that turns a track to automatic record arm when I enable the track. This cuts down on some of the problems but when I have a large session with lots of auto armed tracks it's almost unusable even on my very fast machine.

There has to be solution either with a clever action, clever mouse modifier or buffering preference.

I've seen the problem get significantly worse updating from v5.5 to 5.7. Was there anything on the dev side that changed with track selection or media buffering?

[heda]

mmmm I'm testing this now in 5.70 and... maybe it has been optimized or something.. it is really fast now...
the only problem I see is enabling/disabling auto-arm for many tracks... but now it is not a problem to have the tracks auto armed and select 1000 tracks. it's fast!

I have posted this while waiting 1000 tracks to disable auto arm... still going...

[juliansader]

Do you perhaps use a Mackie Control Surface? (Or any other device that may be incompatible?)

There was a bug report, Poor performance with very large track counts and Mackie Control surface (with some more discussion over at VI-Control: Reaper – inexplicable CPU load on a blank template).

Other possibilities:

* Running lots of heavy scripts in the background.

* Graphics driver incompatibility with some plugins' graphics acceleration, as reported in Some plugins make deferred scripts very slow, even if plugin is offline.

* Several threads, including Reaper 5, sluggish graphics! (SOLVED), speculate that such problems may be caused by corrupted ini files. Have you tried your template on a portable install?

Does REAPER get snappier again if you revert to an earlier version?

[srdmusic]

Here's my template in case you guys want to test on your end.

LINK: https://www.dropbox.com/s/m6ll2o3v9j...PLATE.RPP?dl=0

You might want to load the template with FX offline so that you don't get a bunch of 'missing plugin errors' on plugins that aren't on your rig.

Can you guys test this.

1) Turn on Auto Rec Arm on a ton of tracks.
2) Open the mixer window and make sure that all the tracks you've armed are visible and their folders are unfolded.
2) Shift click to select the tracks that you've have on auto arm. Keep holding shift to make sure Reaper is actually selecting more than one track. On my rig it sometimes reverts to only selecting one track if I don't hold shift until it's done selecting all the tracks.

On my rig Reaper immediately freezes for a very long time sometimes forever and I have to force quite.

My guess is that it's a bug with anticipatory fx, media buffering on selected tracks, with auto arm is on an the mixer is visible.

[srdmusic]

Originally Posted by juliansader

Do you perhaps use a Mackie Control Surface? (Or any other device that may be incompatible?)

There was a bug report, Poor performance with very large track counts and Mackie Control surface (with some more discussion over at VI-Control: Reaper – inexplicable CPU load on a blank template).

Other possibilities:

* Running lots of heavy scripts in the background.

* Graphics driver incompatibility with some plugins' graphics acceleration, as reported in Some plugins make deferred scripts very slow, even if plugin is offline.

* Several threads, including Reaper 5, sluggish graphics! (SOLVED), speculate that such problems may be caused by corrupted ini files. Have you tried your template on a portable install?

Does REAPER get snappier again if you revert to an earlier version?

Thanks for the suggestions Julian,

I do run two scripts that check which track I'm on. They've never given me a problem before but it's possible that they are having problem with Reaper now. The Scripts are call LBX Stripper and LBX SMART CONTROLS. I'll contact the scriptwriter and see if there is something related to the stripts that could also be slowing us down.

[juliansader]

I have tested the template and everything seems fine here:

* Load template (all FX appear to be offline, and 51 audio files could not be loaded)

* Mixer is open.

* Un-collapse all folders.

* Select all tracks, and set auto-arm for all tracks.

Shift-select all tracks or subsets of tracks work instantaneously. Anticipatory FX allow/disallow does not make any difference.

[srdmusic]

Originally Posted by juliansader

I have tested the template and everything seems fine here:

* Load template (all FX appear to be offline, and 51 audio files could not be loaded)

* Mixer is open.

* Un-collapse all folders.

* Select all tracks, and set auto-arm for all tracks.

Shift-select all tracks or subsets of tracks work instantaneously. Anticipatory FX allow/disallow does not make any difference.

Interesting. So it may be related to my theme, scripts or plugins. I'll do more investigating.

[heda]

tested your template.... all goes fast... uncollapsing all tracks took some seconds.
All is fine except making many tracks auto arm. That's very slow. That always has been slow for me too.

[srdmusic]

Thank you guys for all the help. That really helped me deduce the problem.

So I think I've solved one of the problems. I've recently changed to a new theme that I was editing. If the theme folder is unzipped instead of saved as a 'ReaperZip' the GUI is extremely slow.

I tested the default 4.0 and 5.0 theme and it everything seems much snappier. One I rezipped the theme file things seem to work much faster.

I am still having one problem that seems to be a bug. Do you guys mind testing this as well.

1) Expand the TCP Track list until it is larger than your screen by either unfolding a lot of tracks or zooming the TCP vertically so that that tracks are large.

2) Marquee select in the arrange area or over media items and force the marquee to scroll the screen. (As in attempt to select items that are outside of your viewable tracks).

Scrolling with the Marquee tool is very sluggish. It seems to refresh the GUI one track at a time. Whereas, scrolling with the scroll bar or on the right side or with the mouse wheel is very fast. It's as if the Marquee tool is not allowing for mouse acceleration or scroll acceleration.

Is there a way around this or are we stuck with slow track scrolling with the Marquee tool?

[juliansader]

Originally Posted by srdmusic

Scrolling with the Marquee tool is very sluggish. It seems to refresh the GUI one track at a time. Whereas, scrolling with the scroll bar or on the right side or with the mouse wheel is very fast. It's as if the Marquee tool is not allowing for mouse acceleration or scroll acceleration.

On my system, marquee scroll is perfectly smooth in your empty template. (Result could perhaps differ if the project is filled with items and automation.)

Originally Posted by heda

All is fine except making many tracks auto arm. That's very slow. That always has been slow for me too.

Strange... Auto arming actions have always been practically instantaneous for me.

Have either of you tested these problems in portable installs?

[heda]

Originally Posted by juliansader

Have either of you tested these problems in portable installs?

same result.. this is new portable install

[juliansader]

Originally Posted by heda

same result.. this is new portable install

Is it in any way affected by the monitoring, recording or input settings, or by the contents of the tracks (such as number of envelopes)?

[heda]

Originally Posted by juliansader

Is it in any way affected by the monitoring, recording or input settings, or by the contents of the tracks (such as number of envelopes)?

I don't think so. In the gif, I just opened that srdmusic template, with a portable install and tried to auto arm some tracks.

[srdmusic]

Originally Posted by heda

I don't think so. In the gif, I just opened that srdmusic template, with a portable install and tried to auto arm some tracks.

Hi Heda,

Yep, I'm still having this same problem. It's taking forever to select the tracks. Zipping up the theme folder seemed to help a little on some things but I'm really have a hard time when there are more than a few auto armed tracks.

If I tried to select more than 30 tracks Reaper essentially crashes. I takes so long that it goes into 'no responsive' mode according to windows. Eventually I could wait ten mins it would finally select all the tracks but I don't ever have the time to wait for 10 mins.

There has to be something in my track setup or possibly a bug that's causing the slow down. I can submit this to the bug reporting section if you guys think it's leaning towards a bug.

Heda, are you seeing the same issue with a portable install of 5.5. I know it's a problem in 5.7 but it would give us some conclusions if we knew it was related to something changed in the recent version.

[juliansader]

I don't know what REAPER does "under the hood" when arming tracks, but do either of you use MIDI keyboards or control surfaces that may perhaps require lengthy communications and synchronization per each armed track?

[Dstruct]

Good hint I think.

[srdmusic]

No control surface. Fo you think it's pref related? I can upload my prefs as well to test.

[Dstruct]

I can arm 100 tracks in an instant here (Core 2 Duo E6700). There was someone in the past with the same issue and I think it was related to an attached control surface (and this slow communication was the limiting factor).

[juliansader]

Originally Posted by srdmusic

No control surface. Fo you think it's pref related? I can upload my prefs as well to test.

It might be -- please do upload your prefs.

(Have you tested your template and computer/hardware on a clean, portable install with no scripts? MIDI keyboard plugged in vs unplugged?)

[srdmusic]

Here a link to my preferences. It would be super handy to know if it's something related to my config.

https://www.dropbox.com/s/zvppd8e6cl...ConfigZip?dl=0

Go through my two rigs and see if there's something related to the scripts and or attached midi devices. The home rig only has the scripts and one 2 midi controllers so I'll start there and report back the results.

[srdmusic]

Some interesting discoveries.

I have two rigs that are essentially identical. I cloned my reaper folder so that all the scripts and preferences are identical.

On my home rig tracks selection and automatic arm work as expected. I select any number of tracks and they select very quickly. I can also create a blank session and add 1000 tracks which disarm and arm very quickly.

On the Studio rig, track selection is very sluggish. I shift click on just four tracks and it takes a second or two to arm them. If I do not continue to hold down shift for the full 1-2 seconds all of the tracks accept the last track that I clicked get unselected. It's as if Reaper is waiting to arm the tracks and then adds them to the track selection if I keep shift held down for the duration. I've double checked my mouse modifiers and they all seem to be working fine.

There must be something between my two machines that is causing the slow down. Could be some midi device waiting for midi clock or something dumb. I'll try unplugging all the midi devices and see what we get on the studio rig.

Stay tuned....

[srdmusic]

I've clone my Reaper preferences, theme and everything I can think of hardware wise between my home and work machine. For some reason my work machine is still having a problem arming more than 5 tracks with considerable gui latency while my home rig is working as expected.

Julian, are you able to replicate the lag in shift selecting multiple auto armed tracks by opening my template? I know Heda was able to replicate the problem but if we can figure out what the trigger of the bug is, I can post this thread on the bug reporting forum.

[juliansader]

I have tested your configuration and template in a portable install on my (relatively slow) traveling notebook, and auto-arming worked fine:

Enabling or disabling auto-arm for all 850 selected tracks takes about 5 seconds. Thereafter, selecting or deselecting auto-armed tracks via shift-click or "Select all tracks" is practically instantaneous.

I am no expert on REAPER configurations, but nothing struck me as suspicious in your settings, scripts or custom actions, except perhaps for the marquee-select problem:

* LBX Stripper and LBX_SRD_SmartKnobs are activated on startup, but these don't appear to have any effect on auto-arming speed.

* The script EXT - Syncronized Track & Mixer folder state is very slow if all tracks in the track list are expanded. However, this is not a deferred script that can run in the background, so I assume it is not causing your problems.

* The slow marquee-select in arrange view may be caused by SRD_Track selection follows item selection, if you are always running that script in the background.

[srdmusic]

So after some further testing I still having the same problem. Here's what I've done to troubleshoot so far.

I disabled all of my midi inputs and outputs since I have quite a bit of hardware synths the could be clogging up the auto record.

I disabled all but 32 in and outputs from my audio interface.

I've tried setting all the tracks to 'force midi input'.

I switched the Reaper theme to the default v5 and the default v4

I used the action 'close all open reascripts' which kills any open script that could possibly be clogging us up.

I deleted the retrospective record track and the Smart knobs tracks from the top of the sequence incase those were possibly still giving us problems.

Nothing seems to fix the problem. Is there a way to see if there are still any other scripts running in the background that could cause this problem?

Also, are you running the sequence is FX- disabled mode? I know there's probably a lot of plugins in there they aren't on your rig but I'm wondering if it's related to having all the plugins on. Perhaps it's related to the automatic delay compensation of the plugins.

Any other ideas you guys might have would be greatly appreciated.

[srdmusic]

I found another discovery. I've created a new project from scratch and Added 1000 tracks.

The first 100 tracks work as expected. I'm able to shift select any number of tracks with auto arm on no problem.

After 100 tracks the lag bug starts to show it self. Also further down the list of tracks, turning on and off auto arm takes quite a bit longer than at the top of the list.

Could this be due to anticipatitory fx processing or maybe live mode on tracks further down the list?

[srdmusic]

Portable install with the default preferences also takes FOREVER..... to turn on auto arm for 1000 tracks.

I'm pretty sure we're in bug territory now. It could be related to something on my installation of Windows or my hardware. I guess the next step is to try this on a clean install of windows.

[srdmusic]

Narrowing down the problem here. On the portable install with a session that included 1000 tracks, automatic record arm takes a long time to select and toggle on and off if the mixer is open and all the tracks are visible. If I close the mixer reaper works as expected. Also, If I hide the tracks in the mixer, reaper works as expected. Also if I fold the tracks in the mixer reaper works as expected. So there is a bug in Reaper having to select the tracks in both the TCP and the MCP at the same time.

Can anyone else confirm this?

[heda]

Mmmm interesting!! I'll try later. I can't now.

[heda]

I notice no difference if the mixer is open or closed. It is still slow auto arming all the tracks. But it really doesn't bother me. Selecting all tracks autoarmed or not, is fast.

[srdmusic]

If I shift click more then say 15 tracks, It takes a few moments for Reaper to select the track and arm them. If I don't hold the shift key down, then Reaper deselects all the tracks accept the last one I've clicked. I'll go ahead and post my finding in the bug forum and see if the dev team finds the same problem.

Thanks again for all your help.

[juliansader]

Originally Posted by srdmusic

Portable install with the default preferences also takes FOREVER..... to turn on auto arm for 1000 tracks.

Originally Posted by heda

I notice no difference if the mixer is open or closed. It is still slow auto arming all the tracks.

After some experimentation, I am now also seeing this slow enabling/disabling of auto-arm.

It appears to be caused only by certain plugins, particularly two samplers: Kontakt and an old VSTSynthFont. (These are the only samplers I have available to test, besides REAPER's own SamplOmatic5000.)

None of the other VSTs or VSTi synths seem to affect the speed of enabling/disabling auto-arm.

The more instances of (online) Kontakt, the slower auto-arm. When Kontakt is bypassed or offline, auto-arm is fast again.

Curiously, Kontakt has this effect even if it is bypassed on the tracks that are being auto-armed. For example, if Kontakt is online in tracks 1-200 and offline in tracks 201-400, the latter tracks are still very slow to enable/disable auto-arm.

Similar to Heda, I notice no difference if the mixer is open or closed.

[winbe]

Hello,

just following your discussion, as I also experience problems - this is quite recent, I thought it could be due to Windows 10 upgrades...

If the audio is playing and I open a fx window with some nice/nig GUI, such as Battery or Kuassa amp sims, the audio stutters for several seconds, and the GUI finally appears.

I also have something similar to the arm track slowness, when I have a mixer view and remove it or make it appear, it can be quite slow to display, I see each track appear one by one.

I will try what you suggest with zipping the Theme!

[srdmusic]

Originally Posted by winbe

Hello,

just following your discussion, as I also experience problems - this is quite recent, I thought it could be due to Windows 10 upgrades...

I will try what you suggest with zipping the Theme!

I'm still having slow GUI problems. Opening plugins, selecting tracks, selecting midi notes and selecting auto armed tracks seem to be getting worse.

Have you found any solutions yet?

[faun2500]

Gets VERY slow here. To the point that it is hard to do anything. CPU is at about 40%. Mem at about 53%. I press play and there is a 4 or 5 second delay before play back!

I have 151 tracks at the moment (a lot inactive though) and does seem to get a problem with high track counts.

I have turned off all anti-virus and other programs running in background.

In my case there is definitely a link between audio buffer rate and lag/slugishness. at 128 samples buffer it is painfully unresponsive but take the buffer rate up to 512 and it is much better.

I do know about buffer rates (been using music computers for 20 years) but it usually affects audio (crackles/drop outs). I am not getting the audio problems with low buffer rate, I am getting really unresponsive GUI.

Why is this?

[airon]

You might want to post a screenshot of your workspace (upload it to something like imgur.com and link to it here).


My GUI slow problems mostly relate to two things. Plugins that instantiate more slowly than others (Fabfilter Pro-Q2 for example) and Reapers way of drawing its views.


I'm not happy with this performance at all yet. Fabfilter Pro-Q2 I can work around. It slows me down a bit. Big deal. But when I close or open a view that's docked (see this screenshot) Reaper does at least two redraw passes.

[faun2500]

Originally Posted by airon

You might want to post a screenshot of your workspace (upload it to something like imgur.com and link to it here).


My GUI slow problems mostly relate to two things. Plugins that instantiate more slowly than others (Fabfilter Pro-Q2 for example) and Reapers way of drawing its views.


I'm not happy with this performance at all yet. Fabfilter Pro-Q2 I can work around. It slows me down a bit. Big deal. But when I close or open a view that's docked (see this screenshot) Reaper does at least two redraw passes.

mmm... I am using pro2 extensively! Is it causing a problem? I often have it open full screen.

[airon]

The Pro-Q2 is fine once the GUI is open. Opening up its GUI is just a little slower than most other plugins I've used. Not by much.


And I think it hogs some of the keyboard during that time. I usually don't have to click in to the arrangement with some other plugins. Not tested every plugin on this. I get the Windows error sound when it happens .

[CQrity]

Anything new here?
I also got this behavior, for me its also apparent in strg+z and that is very annoying.