Old 06-19-2019, 07:05 AM   #41
_Stevie_
Human being with feelings
 
_Stevie_'s Avatar
 
Join Date: Oct 2017
Posts: 2,767
Default

Quote:
Originally Posted by EvilDragon View Post
It's pretty easy to just start duplicating tracks and see where it gets ya, though. With or without plugins on it...
True, I forgot, the issue still exists without any plugins on the tracks!

Quote:
Originally Posted by EvilDragon View Post
The question is - will devs support this particular workflow by required optimizations (which I'm hoping are still possible)?
Well yeah, they would definitely make a LOT of media composers happy.
__________________
My Reascripts forum thread | My Reascripts on GitHub | Stephan Römer - film composer
If you wish to donate for my scripts: please consider an organization like: animal shelter, doctors without borders, UNICEF, etc...
_Stevie_ is online now   Reply With Quote
Old 06-19-2019, 07:06 AM   #42
Travesty
Human being with feelings
 
Travesty's Avatar
 
Join Date: Nov 2014
Posts: 506
Default

I ended going with the modular track template based setup, where you load things in as you need them, similar to how lucor ended up working, so I don't have an example project. Though I do still run into the performance hit as a project expands.
Travesty is offline   Reply With Quote
Old 06-19-2019, 08:14 AM   #43
Michael Firmont
Human being with feelings
 
Join Date: Nov 2018
Posts: 10
Default

Support for composer needs :-)) Thanks ED!
Michael Firmont is offline   Reply With Quote
Old 06-19-2019, 09:17 AM   #44
JHughes
Human being with feelings
 
JHughes's Avatar
 
Join Date: Aug 2007
Location: Too close to Charlotte, NC
Posts: 3,412
Default

Quote:
Originally Posted by mustgroove View Post
I'm definitely all for GPU acceleration in Reaper too, I guess the question is how to do that in a cross-platform way given OpenGL's deprecation on Mac.
Vulkan is cross-platform. I don't know how it relates to 2D though.
__________________
You can only Reverse, Switch, Invert or Flip POLARITY, not "PHASE".
JHughes is offline   Reply With Quote
Old 06-19-2019, 12:03 PM   #45
MRMJP
Human being with feelings
 
MRMJP's Avatar
 
Join Date: May 2016
Location: Milwaukee, WI USA
Posts: 1,888
Default

I'm not sure if this is related to this pre-release, or the beta of the 6.0 theme, but the tops of items looks strange since this update. There are some grey notches, I assume where maybe some text should be, or is but can't be read.

UPDATE: I toggled to the default theme and the issue is still there, so maybe it's related to this pre-release.

__________________
iMac Pro 3.0GHz 10-Core • 64GB RAM • SSD • MacOS 10.14.6 RME AES HDSPe
Mac Mini 3.2 GHz Intel Core i7 (6-Core) • 32GB RAM • SSD • MacOS 10.14.6 RME AES HDSPe
https://www.mysteryroommastering.com/ - https://www.justincarlperkins.com/
MRMJP is offline   Reply With Quote
Old 06-19-2019, 12:26 PM   #46
Mordi
Human being with feelings
 
Mordi's Avatar
 
Join Date: May 2014
Location: Norway
Posts: 543
Default

Quote:
Originally Posted by schwa View Post
You can currently render selected tracks, within selected regions, via the master, or not via the master. And of course you can just render the master within selected regions.

Adding support to the region render matrix so you could render different sets of tracks within different regions via the master or not via the master gets kind of complicated!
I was not aware that rendering a region via selected tracks through the master track is possible. That makes my feature request obsolete, I suppose. I'll have to check that out.

Quote:
Originally Posted by timothys_monster View Post
So, you want to render a region without the Master FX chain?
I have a workflow where my regions are named and colored after the track they should render through. I then run a script that compares them, and plots out the render matrix accordingly.

This works well, except that I have no way to run a final pass through a single FX chain when rendering.
Mordi is offline   Reply With Quote
Old 06-19-2019, 04:47 PM   #47
Breeder
Human being with feelings
 
Breeder's Avatar
 
Join Date: Nov 2010
Location: Croatia
Posts: 2,137
Default

Quote:
Originally Posted by Michael Firmont View Post
Support for composer needs :-)) Thanks ED!
Yes, please! This will pretty much make REAPER the best composing DAW on the planet. I consider myself power user and I tried every DAW there is until the result spoke for itself - REAPER needs user time to set up properly, but once done...nothing on the market, let me repeat that...nothing on the market...can touch it. You can have every feature from every DAW in some way or another and then some more because you can create your own stuff after you've built what you needed. And whoever tried composing with hundreds of tracks for real understands what a luxury is to be able to do so many stuff in REAPER. I do not predict the future, but I will not be surprised if more and more composers embrace REAPER with time.

You can do with drum maps instead of expression maps and notation editor is usable in real life scenario (I can vouch it works pefectly with proper MIDI Editor setup...best part, once you set up MIDI Editor properly, a lot of stuff in Notation editor becomes so nice. You just have to know your shortcuts really well to pretty much fly if you don't need to mess with articulations much. And I personally use it mostly to edit rhytm because it's much easier to think like that using notation)

But you can't do with REAPER using so many resources on zero used tracks that only have offline FX on them and MIDI input turned on.

Another problem is that even when you mute and turn on the option to not process muted tracks you still have abnormal RT CPU usage which wastes precious CPU. When you work with many instruments, you simply use up things too quickly that way. We're still waiting on quantum computers and I doubt composers will be able to say they can breathe freely until we get those. And until then, we could really use that CPU to make music.

In the end, Justin always liked a good challenge and hopefully this could still be reworked in REAPER. Feature locks are a nasty thing and I hope there aren't any here.
Breeder is offline   Reply With Quote
Old 06-19-2019, 05:18 PM   #48
_Stevie_
Human being with feelings
 
_Stevie_'s Avatar
 
Join Date: Oct 2017
Posts: 2,767
Default

Couldn’t agree more about what Breeder said!!!
__________________
My Reascripts forum thread | My Reascripts on GitHub | Stephan Römer - film composer
If you wish to donate for my scripts: please consider an organization like: animal shelter, doctors without borders, UNICEF, etc...
_Stevie_ is online now   Reply With Quote
Old 06-20-2019, 10:45 AM   #49
jacques mk2
Human being with feelings
 
Join Date: May 2008
Location: France
Posts: 135
Default

Quote:
Originally Posted by EvilDragon View Post
My question for devs is: considering HiDPI support and the need to calculate more and more pixels for bigger and bigger monitors... how about introducing GPU acceleration to Reaper, so that running a project with 100s of tracks doesn't become impossible to use because GUI becomes way too sluggish because it's calculated by the CPU?

How about some optimizations in that direction?
I totally agree.

Until a real solution is found out regarding this problem, I have to work with another daw...a pity...
__________________
Reaper's community rocks...
jacques mk2 is offline   Reply With Quote
Old 06-20-2019, 03:03 PM   #50
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 599
Default

Quote:
Originally Posted by EvilDragon View Post
My question for devs is: considering HiDPI support and the need to calculate more and more pixels for bigger and bigger monitors... how about introducing GPU acceleration to Reaper, so that running a project with 100s of tracks doesn't become impossible to use because GUI becomes way too sluggish because it's calculated by the CPU?

How about some optimizations in that direction?
I couldn't agree more. I understand the initial need for Reaper to control everything that that the CPU is doing. This is useful on slower machines where it might cause audio glitches to be sending calls the the GPU. However, for systems with even slightly powerful graphics cards there should be an option to process the GUI, Plugin windows and video on the GPU instead of the CPU. This is such an untapped power resource and I can't really think of a good reason why this shouldn't an option.
srdmusic is offline   Reply With Quote
Old 06-20-2019, 03:07 PM   #51
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 599
Default

Quote:
Originally Posted by EvilDragon View Post
The issue also happens for non-HiDPI users. Large number of tracks bogs down the response of the UI considerably, sometimes to the point of unusable. GUI accelleration would help here, and relieve the load from the CPU. Both HiDPI and non-HiDPI users would benefit...
You are totally right about the HiDPI version. Processing video and even track counts around the 300+ are starting to really take down my system. I have a 48 core 3.0Ghz machine. If the gui and video are taking down my machine, then laptops and most desktops don't stand a chance. This is really easy to avoid if we as users were allow to choose what's processed on the GPU and not on the CPU.
srdmusic is offline   Reply With Quote
Old 06-20-2019, 03:08 PM   #52
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 599
Default

Quote:
Originally Posted by Michael Firmont View Post
Support for composer needs :-)) Thanks ED!
+1 Thanks
srdmusic is offline   Reply With Quote
Old 06-21-2019, 03:27 PM   #53
Thonex
Human being with feelings
 
Join Date: May 2018
Location: Los Angeles
Posts: 748
Default

Quote:
Originally Posted by EvilDragon View Post
It's pretty easy to just start duplicating tracks and see where it gets ya, though. With or without plugins on it...

The problem is evident and does exist. The question is - will devs support this particular workflow by required optimizations (which I'm hoping are still possible)?
Yeah.... I was wondering where my lagginess was happening with larger projects. I thought maybe Kontakt was somewhat the culprit, but I think simple track count may be.

+1 on anything that can be done to mitigate lagginess on large templates. A "Deactivate Track" option would be lovely.

Cheers,

Andrew K
__________________
Cheers,
Andrew K
v5.982/64 Mac 10.12.+, i7 Quad 2.9GHz, 24GB
Thonex is offline   Reply With Quote
Old 06-22-2019, 01:12 AM   #54
sonicowl
Human being with feelings
 
sonicowl's Avatar
 
Join Date: Oct 2015
Posts: 347
Default

Wouldn't it be possible with a script to save track as template, and somehow replace it with dummy "image", which is just graphic representation of a track, but using no resources at all? And when track is reactivated, the track is loaded back from template? Something like that...
sonicowl is offline   Reply With Quote
Old 06-22-2019, 08:40 AM   #55
Breeder
Human being with feelings
 
Breeder's Avatar
 
Join Date: Nov 2010
Location: Croatia
Posts: 2,137
Default

Quote:
Originally Posted by sonicowl View Post
Wouldn't it be possible with a script to save track as template, and somehow replace it with dummy "image", which is just graphic representation of a track, but using no resources at all? And when track is reactivated, the track is loaded back from template? Something like that...
No, because whatever you do, empty track does waste CPU . Or at least it seems so because none of use have been able to find the preference to disable it.

Let me repeat that there is an option to disable muted tracks, but it also seems CPU is getting wasted even if that's the case. I really wonder if it's the GUI code or something else at play here

Last edited by Breeder; 06-22-2019 at 08:45 AM.
Breeder is offline   Reply With Quote
Old 06-22-2019, 11:23 AM   #56
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 599
Default

Quote:
Originally Posted by Justin View Post
I might be wrong but I don't think rendering of pixels is the expensive part, usually the slowness comes from getting peaks data from disk etc. (a good test would be to try disabling peaks display in the prefs and see how that helps).
Hi Justin,

Thanks again for taking to the time to listen to our requests. I wanted to give you a few of the many examples of GUI sluggishness that makes Reaper feel less powerful than it really is. I have example of sessions I can send you if you need to more help narrowing down what might be causing this sluggishness.

1) On the PC side, video playback stutters on in Reaper using VLC or FFmepg but when playing the same video on VLC player stand alone application the video plays smoothly. This happens in empty sessions with no scripts running on portable installs.

2) Reaper's GUI and video playback halts anytime a user hits the action to undo.

3) Some scripts that need high refresh rates to display visual feature make the GUI and video playback halts or becomes sluggish.

4) Marquee selecting item down a list of TCP tracks, where the screen needs to scroll down to a track that is not currently being displayed, the GUI redraw rate is extremely slow. If the user has to marquee select from track number 1 down to track number 300 for example the user will be sitting there for a very long time watching Reaper redraw the TCP track by track.

5) When the user hits save or Reaper is making a back up, the entire GUI and video playback halts. (the save thing I kind of get but backing up a file seems like that should be more of a background process that doesn't take down my session)

6) In the midi editor, I use some of Julian's midi tools like the one that draws a linear ramp of midi CC nodes. The GUI become extremely slow when the CPU is above 50%. If I'm playing the session back and trying to draw a line while it plays, the GUI refresh almost comes to a halt.

7) Some VSTi GUIs use the CPU instead of the GPU to process their interface. I can point you to specific example of a Kontakt instrument interface that takes down the entire Reaper GUI when floating it or docking it in the FX chain.

8) In larger sessions, track selection becomes very slow at the bottom of the session. Sometime more than 10 seconds to select tracks.

Most of these issues seem to be avoidable if the user had the option to run Reaper's GUI and Video playback on the GPU instead of the CPU. I understand that in a very small pool of users with slower machines that might see slightly less performance on the audio side if they processed the GUI on the video card. This is why I believe there should be a check box in the advance settings 'Allow Graphics Acceleration for Reaper GUI, scripts and Video playback'. That way users have the option. The GPU is such an untapped resource here and hope you can see in the above examples that when we are taxing our CPU then we really do need any extra power that the GPU can provide.
srdmusic is offline   Reply With Quote
Old 06-22-2019, 11:35 AM   #57
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 599
Default

Quote:
Originally Posted by Justin View Post
Maybe tell REAPER not to use all your cores (N-1?)?
Can we get a little clarification on how this might help us? I think what you are saying is that if we disable thread #1 for example, that might give the OS and other applications control over that thread and therefore help Reaper not have clashes. Otherwise I'm not quite sure how giving one less CPU thread to Reaper would help the GUI run faster. From what I'm seeing, my Reaper sessions are using up all the power on one or more cores when that happens, the GUI becomes sluggish because Reaper needs the CPU cycle to process the GUI at the same time. If I tell reaper to use one less thread, would that force reaper to process all of the GUI on thread #1 and then the rest of 47 open threads could process audio and everything else?

If developing graphics acceleration in Reaper would take a lot of time which you guys are already taxed on trying to get V6 out, would it be possible to give the user the option to process the GUI, video and script visuals on specific cores/ threads and all the audio processing on other specific cores/ threads?
srdmusic is offline   Reply With Quote
Old 06-22-2019, 11:38 AM   #58
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 599
Default

Quote:
Originally Posted by Breeder View Post
No, because whatever you do, empty track does waste CPU . Or at least it seems so because none of use have been able to find the preference to disable it.

Let me repeat that there is an option to disable muted tracks, but it also seems CPU is getting wasted even if that's the case. I really wonder if it's the GUI code or something else at play here
I have also experienced this. Even with all the VSTs offline and the track muted the track uses CPU and some ram. I understand the ram thing but it shouldn't be using as much CPU as it is. My guess is yes, this is related to the track GUI needing the CPU to render the image rather than using the GPU.
srdmusic is offline   Reply With Quote
Old 06-22-2019, 11:43 AM   #59
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 599
Default

Quote:
Originally Posted by Breeder View Post
But you can't do with REAPER using so many resources on zero used tracks that only have offline FX on them and MIDI input turned on.
I haven't tested this but if you turn MID input off, does the CPU reduce at all? If so, it would be very easy to create a custom action to 'online FX, unmute the track and set the midi input'.

My guess is that even empty muted tracks with no input are still taking up CPU cycles because they are still running the GUI bit on the CPU.
srdmusic is offline   Reply With Quote
Old 06-22-2019, 03:54 PM   #60
Breeder
Human being with feelings
 
Breeder's Avatar
 
Join Date: Nov 2010
Location: Croatia
Posts: 2,137
Default

Quote:
Originally Posted by srdmusic View Post
My guess is yes, this is related to the track GUI needing the CPU to render the image rather than using the GPU.
But most of the interface is hidden both in arrange and mixer, it's not like it's all rendering to screen simultaneously - there must be optimizations like that in the code. God knows what it is, I hope they figure it out
Breeder is offline   Reply With Quote
Old 06-23-2019, 03:13 AM   #61
sonicowl
Human being with feelings
 
sonicowl's Avatar
 
Join Date: Oct 2015
Posts: 347
Default

Quote:
Originally Posted by srdmusic View Post
My guess is that even empty muted tracks with no input are still taking up CPU cycles because they are still running the GUI bit on the CPU.
Cannot be GUI related. Just tested it, created 2048 tracks, all record disabled and not routed to master, so they are just sitting there, not getting input and not sending to master. This gives me RT CPU around 50% and total CPU at 20%.
Then I make them all hidden in TCP and MCP, GUI is empty. CPU usage remains exactly the same, no matter if all tracks were visible or hidden. So even if GUI is empty there is still high CPU usage from empty disconnected tracks. Therefore it cannot be GUI related imo.
sonicowl is offline   Reply With Quote
Old 06-23-2019, 05:14 AM   #62
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 2,752
Default

Quote:
Originally Posted by mccrabney View Post
regarding laggy GUI - here's an anecdote i hope is on topic.

i experience much greater lag when using (one midi editor per project / open all midi in project / all midi visible, other tracks at 2 opacity).

if i instead show only the single track midi, i don't get the same lag.

this rears its head once the rpp grows more complex. for reference, i experience this with ~8 midi tracks containing single channel midi items containing non-outrageous, often monophonic melody lines with the occasional pitchbend/cc movements.

unfortunately, the scenario of a complex project is precisely where seeing all project midi is helpful - but this is when the UI lag occurs. i'm lucky that most of my songs are nearing completion at around the time when this UI lag starts being a problem.
Strangely, the MIDI editor got much slower since v5.00: MIDI editor: Recent versions get unnecessarily bogged down if multiple takes visible.

The MIDI editor's equivalent of hidden or muted tracks taking up CPU, is that
* MIDI items with multiple takes bog down the editor terribly, even though these non-active takes are not visible in the editor (or even in arrange), and are obviously not being edited. They do not need to be re-analyzed and re-drawn in any way.
* Similarly, the MIDI editor gets bogged down by MIDI items that are editable but do not have visible MIDI in either the editor or the arrange view.


Quote:
Originally Posted by Breeder View Post
But most of the interface is hidden both in arrange and mixer, it's not like it's all rendering to screen simultaneously - there must be optimizations like that in the code. God knows what it is, I hope they figure it out
REAPER is renowned for its highly efficient and optimized audio engine. I hope that the same skills will be applied to the GUI -- and the MIDI editor:
* Takes that haven't been changed, should not be re-analyzed, and only mimimal re-drawing of the MIDI data should performed, if any MIDI data is visible in the editor.
* Takes that have no MIDI data visible in the MIDI editor, should not have any effect on the MIDI editor's responsiveness.
juliansader is offline   Reply With Quote
Old 06-23-2019, 05:44 AM   #63
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 10,248
Default

Quote:
Originally Posted by juliansader View Post
* MIDI items with multiple takes bog down the editor terribly, even though these non-active takes are not visible in the editor (or even in arrange), and are obviously not being edited. They do not need to be re-analyzed and re-drawn in any way.
This seems like something that would be easy to fix if it were the case, but I can't reproduce it at all. Can you provide an example?
schwa is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 08:28 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.