v5.980+dev0713 - July 13 2019

[vitalker]

v5.980+dev0713 - July 13 2019

• # More large-track-count optimizations (particularly when pasting tracks)

This thread is for pre-release features discussion. Use the Feature Requests forum for other requests.

Changelog - Pre-Releases

Generated by X-Raym's REAPER ChangeLog to BBCode

[airon]

That's promising. Big sessions man. I'm using Reaper for all kinds of reasons, and one is speed.

What optimizations are there ? I could test for specifics that once I knew.

I have one or two smaller niggles to keep the work flowing a little better on larger sessions. One such nuisance is the accidental creation of very small loops when all you wanted to do is position the edit/play cursor(time+loop is default in arrangement and upper half of items for me). A minimum loop length in ms would help, off by default I should imagine. 100ms? The other is the almost total freeze of Reaper if during playback the user changes a loop edge by dragging with the mouse or creating a new loop, and the playhead is close to a loop edge. It's the only instance in recent memory in which I had to kill off the Reaper process.

[mustgroove]

No change in mixer window scrolling sluggishness for me.

[EvilDragon]

Testing the copy-paste tracks improvements:

Simple select all->copy->paste got me to 4096 tracks, but then Reaper is completely unresponsive to mouse operation (doesn't open any menus or dialogs - transport works but Reaper itself is not very usable).

Much better than before, where I got a system halt where I couldn't do anything and had to restart computer completely. Still, I don't think the above would be expected behavior no matter how many tracks there are in the project.


I think the main problem here is that Reaper needs more CPU for housekeeping tracks compared to other DAWs. There need to be more optimizations here. At 2048 tracks Reaper is taking up over 35% of RT CPU...

[_Stevie_]

Yup! I’m with ED here.

[DANIELE]

Originally Posted by _Stevie_

Yup! I’m with ED here.

Yeah, me too!

[nappies]

Originally Posted by _Stevie_

Yup! I’m with ED here.

+100500!

[Triode]

Originally Posted by nappies

+100500!

What - plus that many tracks in your sessions?

[srdmusic]

Originally Posted by vitalker

v5.980+dev0713 - July 13 2019
[list] # More large-track-count optimizations (particularly when pasting tracks)

THANK YOU THANK YOU THANK YOU THANK YOU!!!!!!!!

[srdmusic]

Originally Posted by EvilDragon

Testing the copy-paste tracks improvements:

Simple select all->copy->paste got me to 4096 tracks, but then Reaper is completely unresponsive to mouse operation (doesn't open any menus or dialogs - transport works but Reaper itself is not very usable).

Much better than before, where I got a system halt where I couldn't do anything and had to restart computer completely. Still, I don't think the above would be expected behavior no matter how many tracks there are in the project.


I think the main problem here is that Reaper needs more CPU for housekeeping tracks compared to other DAWs. There need to be more optimizations here. At 2048 tracks Reaper is taking up over 35% of RT CPU...

I agree. Blank tracks or muted tracks need to use not CPU at all like in Cubase.

[jrengmusic]

Media item vol knob and buttons with HiDPI theme drawn very tiny.

I’ve tried to replace the images with 200% scale, but the problem persist.

REAPER v5.980+dev0713



REAPER v5.980

[bFooz]

Originally Posted by airon

One such nuisance is the accidental creation of very small loops when all you wanted to do is position the edit/play cursor(time+loop is default in arrangement and upper half of items for me).

older report: https://forum.cockos.com/showthread.php?t=190580

[MaXyM]

Originally Posted by jrengmusic

Media item vol knob and buttons with HiDPI theme drawn very tiny.

I’ve tried to replace the images with 200% scale, but the problem persist.

REAPER v5.980+dev0713



REAPER v5.980

Does your theme use global_scale?
If so, then yes, it's the case. Gfx elements which are not affected by global_scale in official releases (v5), in recent dev builds the greater global_scale, the smaller gfx element.

I reported it already here. There is Junstin's answer too

In addition to this, icons displayed on top of midi/recording items, got size boundaries recently. Somebody has already noticed it a few days ago link.

[jrengmusic]

Originally Posted by MaXyM

Does your theme use global_scale?
If so, then yes, it's the case. Gfx elements which are not affected by global_scale in official releases (v5), in recent dev builds the greater global_scale, the smaller gfx element.

I reported it already here. There is Junstin's answer too

In addition to this, icons displayed on top of midi/recording items, got size boundaries recently. Somebody has already noticed it a few days ago link.

Ah...yes. Because my theme specifically build for Retina/HiDPi monitors @2x scale.

If global_scale was deprecated, how does we define Retina/HiDPi theme?

[MaXyM]

Don't know how it will work in final v6, but in recent dev builds, DPIscale found in Preferences is kinda decoupled from global_scale. So, instead of using global scale, set DPI scale in preferences to 2.0 (and comment out global_scale in rtconfig)

BTW It is how I found it working this way in Windows (in case you are using other OS)

Be aware, pink/yellow marked areas are also scaled (in a meaning of changing pixel density) in recent builds. If you layout, element alignment-wise depends on those areas, expect some distortion.

[Yanick]

Awesome! Now zoom works great for over a hundred tracks - especially this: View: Adjust selected track heights (MIDI CC relative/mousewheel)
Now you need to open the mixer without slowing with the same number of tracks (until I saw the difference)

[Yanick]

Originally Posted by Yanick

(until I saw the difference)

although not, there is a little difference

[Yanick]

I would like to make it so that a separate master channel does not flicker
https://drive.google.com/file/d/1EM5...IxKCPLHkz/view
I'm testing now on windows 10 LTSB, i5 8250u, uhd 620

[_Stevie_]

I don't think this is a new behavior (I think I reported it in some earlier pre cycles), but since it fits the GUI performance enhancements, here we go:

When clicking with the mouse on a fader and moving it, it stutters, gets laggy and even skips some movements (see gif). I grouped some faders to make the effect more obvious.

This does NOT happen, when an external device controls this fader (control surface) or
when, for example, using the fader from HeDa Track Inspector.

https://imgur.com/aUieSLu

[Nathannn]

I tried inserting 1 million tracks and reaper froze...why?

[vitalker]

Originally Posted by Nathannn

I tried inserting 1 million tracks and reaper froze...why?

Actually it's not bad, cause previously your computer would stuck.

[krahosk]

Sorry guys if this has been mentioned before or if it's at the wrong place.



This occurs in the "track" and "media item" color mode only.
Mute is simply not indicated.

[EvilDragon]

Originally Posted by Nathannn

I tried inserting 1 million tracks and reaper froze...why?

"I overclocked my CPU to 15 GHz and it melted... why?

[musicbynumbers]

Originally Posted by Nathannn

I tried inserting 1 million tracks and reaper froze...why?

Justin.. please come up with a smart ass comment that pops up if you try and add a silly number of tracks!

[Valle]

Hehe ... I tried EvilDragon’s test with inserting 4096 tracks, and REAPER went “WTF is your problem, man?”, and then it all froze like water on Triton ...

I envy all you guys who can, not only retain control over hundreds and hundreds of tracks, but also produce music that sounds ... great.

But then again, if my thoughts ever mattered, I’d hope for the DEVs to focus on more relevant things than an impressive track count that is hardly ever needed by any but the fraction who use 200 tracks for drums only (I'm not saying ED is one of them!).

[Tale]

I can add up to 2048 empty tracks (on Win10), but REAPER crashes if I add the next 512. I have yet to figure out at which exact number it crashes, and if this also happens on the macOS.

I did notice that the vertical scroll bar handle initially got smaller while adding tracks, but after adding the last 512 it suddenly got big again (as if there were only 1 or 2 tracks). Anyhoo...

EDIT: REAPER x64 On Win10 seems to crash around 2430 tracks, but the exact number varies. I now also noticed that just before the "Save As" dialog box looks weird (missing buttons, black icons), so it seems like it's running out of resource memory somehow (eventhough I still have >12 GB available).

On macOS (10.13.6) I can easily create 8192 tracks, after which I gave up. So it would seem that the crashes are Windows only.

[EvilDragon]

Originally Posted by Valle

Hehe ... I tried EvilDragon’s test with inserting 4096 tracks, and REAPER went “WTF is your problem, man?”, and then it all froze like water on Triton ...

I envy all you guys who can, not only retain control over hundreds and hundreds of tracks, but also produce music that sounds ... great.

But then again, if my thoughts ever mattered, I’d hope for the DEVs to focus on more relevant things than an impressive track count that is hardly ever needed by any but the fraction who use 200 tracks for drums only (I'm not saying ED is one of them!).

The point is not in using all 4000+ tracks at once in a mix. The point is in creating a huge orchestral template with lots of instruments and synths loaded, lots of variations, all available at a drop of a hat, once you organize things properly in subfolders...


Also, optimizing behavior at large track counts is still an optimization that carries all the way through the app, even with low track counts (but obviously, it wouldn't make a huge difference with low track counts). Surely it should be more important for Reaper to be able to do the same things most other DAWs can do w.r.t. high track counts without their GUIs being frozen and unusable mess? This is exactly the workflow many working composers are using day in, day out, and currently Reaper doesn't support it very well.

[mccrabney]

fwiw i am finally converting my live set from reaper to ableton, and ending up with hundreds of tracks (or whatever they're called there). i accidentally hit Ctrl A in the wrong field and ableton took several seconds to select/deselect all scene/tracks etc.

these scenarios/issues aren't uncommon in other daws/programs, so it's another area where reaper will have an opportunity to shine. it sucks to reach a program's ceiling, because it so often seems to happen just when your project is hitting its stride, and it gives the not necessarily correct impression that developers don't have "pros in mind"

[srdmusic]

When I first started using Reaper I recreated my Cubase orchestral template which was about 2500 tracks. In Cubase when a track and plugins are disabled they use no CPU or so little that it's not easy to measure. So a user could have every one of there favorite track presets in the session with the all the plugins disabled and the CPU meter would be at about 5%. The CPU obviously goes up once the user start enabling tracks. This is the part the Reaper shines at. Reaper can handle more tracks the are enabled than Cubase because of the anticipatory fx and other great buffering innovations. Where Reaper starts to fall apart is GUI lag with that many tracks in the session. This GUI lag problem has gotten progressively worse over that past 3 years I've been working within Reaper. This is not necessarily Reaper's fault. All the newest plugins I'm using on my buses are taking up a lot more CPU then my buss plugins did 3 years ago. The CPU usage is going to get progressively worse as plugins will evidently use more CPU over time. I have been forced to remove all of my template tracks and just have buss tracks and folders in my template. I now have work with track template instead of the way I would prefer where all the tracks are loaded in the session.

I believe the most elegant solution the DEVs could implement is to allow the user the option to run the GUI, video playback and script interfaces on the GPU and open up graphics acceleration. There is absolutely no way us users can give up more CPU power, we are all in our own way hitting the max of what our CPU's can do. The GPU is such an untapped resource.

I think I understand why the DEVs initially wrote Reaper to run the GUI on the CPU, If Reaper has control of CPU priory in every aspect possible then there is less chance of the OS causing CPU overruns/ Audio glitches. However, I would be willing to bet that even on very old and slow laptops the CPU cycle gains for having Reaper control the GUI on the CPU would not equal the gains of cycles on even the worst possible on-board graphics card.

Devs, I have access to 6 machines with Reaper 64bit installed. Some are Mac OSX and Some are Windows 10 one is Windows 8.1 A composer friend of mine also has 2 test Linux machines. These machines range from very old laptops to very powerful CPU an GPUs. Most of the machines are Intel based but one machine has the new 32 core/64 thread AMD Threadripper. Each machine has a different model graphics card. I have two other composer friends, one is on AMD the other is on Intel. We have discussed at length about our experienced with GUI lag at high tracks counts and we are all willing to run some extensive testing on our machines to so you guys have a larger than normal sample pool of test machines.

Justin, I did see that there were some recent additions on the Mac OSX side to utilize 'Metal'. Please correct me if I'm wrong but I believe this opens up graphics acceleration in Reaper for Mac users. I know Windows can be more troublesome on that side of things so perhaps the best way to help you test would be to compile two separate versions of Reaper 64 Windows so that we can open sessions in both version and send you back the CPU usage result. You guys did something similarly when you compiled Reaper in the VC + ICC compiler test. Either two separate version or a checkbox in preferences to switch between would do the trick.

GUI optimization and full envelope support (line and curve) in the MIDI editor are my personal hopes for Reaper v6.

If there is any suggestion you DEVs have in helping with the testing process my friends and I will gladly do our part as the burden of testing these sorts of major revisions should not be solely on you DEV.

[deeb]

I guess sensible optimization is always great. I am hoping a way for optimize copying paste envelopes, ais and items without hassle too ,... Coff coff area selection. Maybe freezing could be avoided and that would optimum! and just display a message "you are out of resoures to add more tracks"? I don't know

[musicbynumbers]

Originally Posted by srdmusic

When I first started using Reaper I recreated my Cubase orchestral template which was about 2500 tracks. In Cubase when a track and plugins are disabled they use no CPU or so little that it's not easy to measure. So a user could have every one of there favorite track presets in the session with the all the plugins disabled and the CPU meter would be at about 5%. The CPU obviously goes up once the user start enabling tracks.

I might be misunderstanding here but have you tried using the offline feature (right click on the fx) rather than bypassing? You can even set it up as an action for selected tracks. That uses no cpu or memory until they are "on-lined"

I use to do my orchestra tracks like this but now load bunches in (like woodwinds) using track templates instead but that might not suit you.

Also, in buffer options, you can try changing behaviour number there as that helped me a lot with massive amounts of tracks (ended up at 0 instead of 4)

On the good side though, there's been a release here a month or so ago of full envelopes in the midi editor but was taken out till it was ready so hopefully that will come back.

[sonicowl]

Originally Posted by musicbynumbers

I might be misunderstanding here but have you tried using the offline feature (right click on the fx) rather than bypassing? You can even set it up as an action for selected tracks. That uses no cpu or memory until they are "on-lined"

Not so. Even empty tracks use a lot of CPU in Reaper. Try yourself. Simply go to Insert/Multiple tracks, and create 1000 empty tracks, and see RT CPU usage in Performance Meter. Then try the same with 2000 tracks. Even if you unroute tracks from all audio buses, still those empty unconnected tracks use almost all CPU. Why?

[srdmusic]

Originally Posted by musicbynumbers

I might be misunderstanding here but have you tried using the offline feature (right click on the fx) rather than bypassing? You can even set it up as an action for selected tracks. That uses no cpu or memory until they are "on-lined"

I use to do my orchestra tracks like this but now load bunches in (like woodwinds) using track templates instead but that might not suit you.

Also, in buffer options, you can try changing behaviour number there as that helped me a lot with massive amounts of tracks (ended up at 0 instead of 4)

On the good side though, there's been a release here a month or so ago of full envelopes in the midi editor but was taken out till it was ready so hopefully that will come back.

Yes, my previous template had all the FX offline and the tracks were muted and the preference to lower CPU usage on muted tracks was selected. As far as I know this does not make the tracks use 0% like other DAW. In larger sessions say 1000+ tracks the CPU start to exponentially go up. I believe part of this is due to the fact the the user interface or image files for the track are running on the CPU and not the GPU. There also may be some sort of anticipatory fx or buffering CPU cycle going on even if there is nothing on the track and no routing.

I have noticed the same thing with buffering. I currently run my sessions at 0 instead of 4. Some of my other composer friends have said the same thing. It seem like if the user has a higher number of CPU cores the lower setting seems to benefit those systems more because typically the single core clocks speeds are lower on higher core count systems.

Oh I am fully aware of the release that included the full envelopes in the MIDI editor. I have dreams about them coming back every night

[EvilDragon]

Originally Posted by srdmusic

There also may be some sort of anticipatory fx or buffering CPU cycle going on even if there is nothing on the track and no routing.

That makes no sense. If there's nothing on the track, there's no media to buffer, and if there's no routing or plugins then there's nothing to anticipatively process.

The CPU usage here is some weird OCD housekeeping Reaper must do for whatever reason, coupled with graphics done by CPU instead of GPU, at least that's my assumption. There has to be a way to optimize this further.

[sonicowl]

Originally Posted by EvilDragon

That makes no sense. If there's nothing on the track, there's no media to buffer, and if there's no routing or plugins then there's nothing to anticipatively process.

The CPU usage here is some weird OCD housekeeping Reaper must do for whatever reason, coupled with graphics done by CPU instead of GPU, at least that's my assumption. There has to be a way to optimize this further.

But why would 1000+ tracks graphics task CPU? Makes no sense. They just sit there doing nothing, like cells in Excel. If it is graphics issue, then hiding all tracks should free all CPU. But this isn't the case. Even if all tracks are unrouted, and all hidden in tcp and mcp, still there is high CPU usage (although it is a bit less).

All tracks unrouted and muted does not reduce CPU.
Prevent media buffering on all tracks - no change.
Prevent anticipative FX on all tracks - no change.
Disable track metering - no change.

If it was graphics issue, then it should go away if all tracks are hidden.
If it was anticipative FX issue, then it should go away by disabling that in Performance options for tracks.

Those tracks process no audio, and are hidden. Why are they eating all the CPU??? I guess Justin is the only one to know the answer (at least I hope he knows what is going on).

[EvilDragon]

That's why I said that there seems to be "some OCD housekeeping thing Reaper must do for whatever reason".


I'd love a straight and direct answer to this from devs as much as everyone. Let's get to the bottom of this!

[jacques mk2]

Same here, little improvements regarding high track count, however UI lags and delayed responses still prevents me to work at ease with heavy loaded projects.
Until now I thought it was only due to CPU limits, however performance meters shows only 50%...

[MRMJP]

Is anybody else noticing an occasional slight delay when using COMMAND/TAB to get back to REAPER from another app such as iZotope RX?

This seems to have started with this pre-release. and isn't project specific.

[lucor]

I can definitely see some GUI responsiveness improvements now. Ultimately though, I really hope that the GUI will be as responsive with 100+ tracks as it is with a single track right now. I don't know if graphics acceleration would be the answer to that problem?!
BTW I hope the midi editor will also get some love during these coming updates, because the lag in there (for me) is even worse in regards to workflow destruction.

[srdmusic]

Originally Posted by sonicowl

But why would 1000+ tracks graphics task CPU? Makes no sense. They just sit there doing nothing, like cells in Excel. If it is graphics issue, then hiding all tracks should free all CPU. But this isn't the case. Even if all tracks are unrouted, and all hidden in tcp and mcp, still there is high CPU usage (although it is a bit less).

All tracks unrouted and muted does not reduce CPU.
Prevent media buffering on all tracks - no change.
Prevent anticipative FX on all tracks - no change.
Disable track metering - no change.

If it was graphics issue, then it should go away if all tracks are hidden.
If it was anticipative FX issue, then it should go away by disabling that in Performance options for tracks.

Those tracks process no audio, and are hidden. Why are they eating all the CPU??? I guess Justin is the only one to know the answer (at least I hope he knows what is going on).

That is interesting. For sure there is some GUI lag on track selection and opening windows that would probably work fast if they ran on the GPU but when Reaper is sitting idle it is strange that the CPU is still chewing through CPU cycles when there is no routing, media or track buffering going on. Maybe it's just Reaper is having the CPU assigned the tracks memory address and for some reason it's having reassign them to address constantly?