v5.980+dev0713 - July 13 2019

[srdmusic]

Originally Posted by 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.

I don't want the DEVs to get the wrong idea about all my posts. Reaper is amazing and I'm never going back to anything else. I am able to load a hell of a lot more plugins in Reaper than in Cubase and I'm able to saturate the CPUs much more stable. The problem comes in only with the last little bit when anything heavy on the graphics side to chop on the CPU.

You bring up a good point about the midi editor. There is a lot more moving pixels going on when playing back midi and using Julians awesome MIDI editor scripts for example. If I am playing back the session and trying to edit at the same time I start to get a lot more CPU spikes than moving things around in the arrange window. If you haven't already gone through the buffer preferences for the MIDI editor, you may want to take a look at that. Reaper gives you the ability to buffer tracks that a open in the midi editor differently then when playing them back in the arrange windows.

[lucor]

Originally Posted by srdmusic

You bring up a good point about the midi editor. There is a lot more moving pixels going on when playing back midi and using Julians awesome MIDI editor scripts for example. If I am playing back the session and trying to edit at the same time I start to get a lot more CPU spikes than moving things around in the arrange window. If you haven't already gone through the buffer preferences for the MIDI editor, you may want to take a look at that. Reaper gives you the ability to buffer tracks that a open in the midi editor differently then when playing them back in the arrange windows.

CPU is fine for me, the main problem I have in the midi editor is that it simply gets impossible to work with due to lag when you have a densely orchestrated piece and want to have all midi data visible at once (which I do 95% of the time for orchestration purposes). Here's an example, which is still quite mild compared to some other projects I have: https://www.youtube.com/watch?v=gXAxRMr665Y

I fully agree with you on REAPER though, now that I'm used to its workflow I don't think I can ever go back to Cubase, and the GUI lag is the only real problem I have left with REAPER (though admittedly it's quite a big problem ).

[mccrabney]

the main problem I have in the midi editor is that it simply gets impossible to work with due to lag when you have a densely orchestrated piece and want to have all midi data visible at once (which I do 95% of the time for orchestration purposes)

this gets me too, and my stuff isn't nearly as densely orchestrated as in your video.

[EvilDragon]

Originally Posted by lucor

CPU is fine for me, the main problem I have in the midi editor is that it simply gets impossible to work with due to lag when you have a densely orchestrated piece and want to have all midi data visible at once (which I do 95% of the time for orchestration purposes). Here's an example, which is still quite mild compared to some other projects I have: https://www.youtube.com/watch?v=gXAxRMr665Y

Might wanna tweak the CCs per quarter note setting and make it less dense.

But in all honesty, Reaper should just not draw any redundant duplicate CC events EVER. This alone would make it so that you always have the very minimum events created that would still result in the curve that you've drawn.

How hard can this be? There's a script that Julian wrote that removes reduntant CCs, but you always have to run it manually after you do your freehand drawing... Cool to have it, but it absolutely breaks workflow.

[srdmusic]

Originally Posted by mccrabney

this gets me too, and my stuff isn't nearly as densely orchestrated as in your video.

I'm assuming you guys have the 'one midi editor per project' option selected in your template.

You may want to mess around with checking the boxes or unchecking the Reaper preferences - Audio - Buffering:

"Allow on tracks with open MIDI editor (will increase MIDI preview latency)". I have that setting checked in preferences and I do see higher CPU usage with the MIDI editor open then in the arrange window. However, with 24 cores/ 48 threads on my machine I only see problems with Kontakt libraries with super high memory usages on single instances. IE. Orchestral Tools or Cinesamples with all the mic positions up.

You may also want to bump up the 'Media Buffering size, pre-buffer, Media Buffer size with per-take FX UI Open, and the anticipatory fx render ahead buffer. Increase those numbers incrementally until you are comfortable. You will have to deal with making changes to plugins and midi where the change is not audible for quite a few ms. But that seems to be ok for me if I can get the MIDI editor to play back properly even with many instruments open at once in the MIDI editor.

Forum users, If I am incorrect in guiding users in this direction please let me know your finding as I still consider myself to be somewhat of a noob at understanding all the intricacies of buffering in Reaper.

[srdmusic]

Originally Posted by EvilDragon

Might wanna tweak the CCs per quarter note setting and make it less dense.

But in all honesty, Reaper should just not draw any redundant duplicate CC events EVER. This alone would make it so that you always have the very minimum events created that would still result in the curve that you've drawn.

How hard can this be? There's a script that Julian wrote that removes redundant CCs, but you always have to run it manually after you do your freehand drawing... Cool to have it, but it absolutely breaks workflow.

That is a pretty great suggestion ED. Hadn't thought about this until now.

Maybe it could be a MIDI editor preference that users could check. Cubase has a check box named something like 'reduce midi CC data' which I believe filters redundant income CC data.

Instead of putting the burden of developing that on the DEVs, the easiest solution would probably be to contact Julian to have him modify his script to be a JFX input plugin that filters all redundant CC and Note inputs. This could be a plugin that is put on every tracks.

The second option would be a little more scripting work but would function more elegantly than a per track solution. This would require the user to funnel all MIDI inputs through one MIDI input like loop back midi or RPT MIDI or some form of this. We could then have a script that filters the redundant data before it gets to the track level.

I know neither of these solution are as elegant as a built in Reaper preference but absolute possible while we wait for a DEV team solution.

[MRMJP]

It's not every time, and it's not a huge lag, but on both of my Macs (specs in signature), using command + TAB to get back to REAPER from another app (RX and Safari for sure), there can be a 1/2 second lag before REAPER shows up.

It's normally always instant.

I can't figure out what triggers this intermittent behavior though.

[D Rocks]

1 million track is 45 times more tracks than there are frequencies in the audible spectrum lol.
That would easily lead to a massive noise chaos (wondering why).

Seriously, maybe optimizing with stress tests up to 1 million can highlight how efficient it is when the code loops often.
But practically this is completely insane to ask a DAW to generate 1 million tracks lol.

[Valle]

Originally Posted by EvilDragon

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...

I see what you mean. But, is that really possible in any DAW – having 4000+ tracks with lots of instruments and synths fully loaded and prepared, ready to fire away as soon as a midi file is being dropped?

[Judders]

Originally Posted by Valle

I see what you mean. But, is that really possible in any DAW – having 4000+ tracks with lots of instruments and synths fully loaded and prepared, ready to fire away as soon as a midi file is being dropped?

You could easily get to 1000 if you have a full orchestra with each articulation as a separate track (as many composers like to do). Then you have choirs, percussion, synths and fx...

To run that you would want VEP in order to use slave machines to host instruments, but if blank tracks are proving to be a problem, then running the actual instruments on slave machines won't help.

[srdmusic]

Originally Posted by Valle

I see what you mean. But, is that really possible in any DAW – having 4000+ tracks with lots of instruments and synths fully loaded and prepared, ready to fire away as soon as a midi file is being dropped?

Some DAWs like FL studio and Abelton fall apart with high track counts from what I've hear heard.

In Cubase it is possible if the tracks are disabled. When disabled, the tracks use no resources other than memory. Or so little resources that it's not really affecting tracks that are enabled. Reaper does not seem to used that much resources when the track count is less than about 500. So there may be something in the code that's not entirely optimized and when we get to those higher track counts the optimization problem become exponentially apparent. It is clear that anything above 500 tracks starts to exponentially tax the Real Time CPU utilization.

If we could get muted tracks and/or tracks that have disabled plugins to on them to use near zero CPU resources then the users that are wanting to have large orchestral templates loaded inside Reaper would be able to work the same as they can in Cubase.

The only downside I've personally seeing in having these higher track counts is that save times increase by a few seconds depending on how many tracks are in the session. I believe the save time thing is unavoidable because the DAW has to save the memory locations of 4000 tracks.

[srdmusic]

Originally Posted by Judders

You could easily get to 1000 if you have a full orchestra with each articulation as a separate track (as many composers like to do). Then you have choirs, percussion, synths and fx...

To run that you would want VEP in order to use slave machines to host instruments, but if blank tracks are proving to be a problem, then running the actual instruments on slave machines won't help.

Exactly, We need return tracks coming back from VEP so even when running the FX outside Reaper will still have the same problem.

[jrengmusic]

Originally Posted by 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.

I couldn’t find dpi scale on prefs in macOS REAPER. So there’s no way to get around this.

[Valle]

Originally Posted by srdmusic

In Cubase it is possible if the tracks are disabled.

You mean disabled as in fully inactivated or "only" muted?

Because, as you know, REAPER allows you to choose whether to let muted tracks being processed or not. When I mute all the tracks in my Gazillion Tracks Project, CPU use (for individual tracks) drops to 0%.

But that's not how I understand the claims being made (I may be wrong, of course) – that "other" (yet to be specified) DAW's can have over 4000 tracks, non-muted, fully loaded with instruments and their samples, ready to fire as soon as a midi file/item is being dropped on to the track. With practically no CPU use ...

I find that hard to believe.

[EvilDragon]

Disabled as in completely disabled - they don't take any CPU or RAM. They're not ready to go at any time - you first need to enable the track if you want to record MIDI/audio to it. But this is the point - you can have a huge number of patches loaded in a project, and you decide when you want to use one.

This is what large orchestral composing templates are all about.

[Valle]

Originally Posted by EvilDragon

Disabled as in completely disabled - they don't take any CPU or RAM. They're not ready to go at any time - you first need to enable the track if you want to record MIDI/audio to it.

OK then, because I understood it differently when you wrote "all available at a drop of a hat" (post #27).

[Judders]

Originally Posted by Valle

OK then, because I understood it differently when you wrote "all available at a drop of a hat" (post #27).

Yes, with a single click. The samples would already be loaded on a slave machine, so no loading times involved, if using VEP.

[Valle]

OK, thanks!

I will leave it at this now because I don't follow anyway. On the other hand, I am an average 30 tracks kind of guy, so ...