|
|
|
06-19-2019, 07:05 AM
|
#41
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
|
Quote:
Originally Posted by EvilDragon
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
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.
|
|
|
06-19-2019, 07:06 AM
|
#42
|
Human being with feelings
Join Date: Nov 2014
Posts: 798
|
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.
|
|
|
06-19-2019, 08:14 AM
|
#43
|
Human being with feelings
Join Date: Nov 2018
Posts: 29
|
Support for composer needs :-)) Thanks ED!
|
|
|
06-19-2019, 09:17 AM
|
#44
|
Banned
Join Date: Aug 2007
Location: Too close to Charlotte, NC
Posts: 3,554
|
Quote:
Originally Posted by mustgroove
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.
|
|
|
06-19-2019, 12:03 PM
|
#45
|
Human being with feelings
Join Date: May 2016
Posts: 2,065
|
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.
__________________
REAPER, just script it bro.
|
|
|
06-19-2019, 12:26 PM
|
#46
|
Human being with feelings
Join Date: May 2014
Location: Norway
Posts: 982
|
Quote:
Originally Posted by schwa
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
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.
|
|
|
06-19-2019, 04:47 PM
|
#47
|
Human being with feelings
Join Date: Nov 2010
Posts: 2,436
|
Quote:
Originally Posted by Michael Firmont
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.
|
|
|
06-19-2019, 05:18 PM
|
#48
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
|
Couldn’t agree more about what Breeder said!!!
|
|
|
06-20-2019, 10:45 AM
|
#49
|
Human being with feelings
Join Date: May 2008
Location: France
Posts: 138
|
Quote:
Originally Posted by EvilDragon
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...
|
|
|
06-20-2019, 03:03 PM
|
#50
|
Human being with feelings
Join Date: Dec 2016
Posts: 876
|
Quote:
Originally Posted by EvilDragon
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.
|
|
|
06-20-2019, 03:07 PM
|
#51
|
Human being with feelings
Join Date: Dec 2016
Posts: 876
|
Quote:
Originally Posted by EvilDragon
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.
|
|
|
06-20-2019, 03:08 PM
|
#52
|
Human being with feelings
Join Date: Dec 2016
Posts: 876
|
Quote:
Originally Posted by Michael Firmont
Support for composer needs :-)) Thanks ED!
|
+1 Thanks
|
|
|
06-21-2019, 03:27 PM
|
#53
|
Human being with feelings
Join Date: May 2018
Location: Los Angeles
Posts: 1,719
|
Quote:
Originally Posted by EvilDragon
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
Reaper v6.80+dev0621 - June 21 2023 • Catalina • Mac Mini 2020 6 core i7 • 64GB RAM • OS: Catalina • 4K monitor • RME RayDAT card with Sync Card and extended Light Pipe.
|
|
|
06-22-2019, 01:12 AM
|
#54
|
Human being with feelings
Join Date: Oct 2015
Posts: 739
|
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...
|
|
|
06-22-2019, 08:40 AM
|
#55
|
Human being with feelings
Join Date: Nov 2010
Posts: 2,436
|
Quote:
Originally Posted by sonicowl
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.
|
|
|
06-22-2019, 11:23 AM
|
#56
|
Human being with feelings
Join Date: Dec 2016
Posts: 876
|
Quote:
Originally Posted by Justin
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.
|
|
|
06-22-2019, 11:35 AM
|
#57
|
Human being with feelings
Join Date: Dec 2016
Posts: 876
|
Quote:
Originally Posted by Justin
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?
|
|
|
06-22-2019, 11:38 AM
|
#58
|
Human being with feelings
Join Date: Dec 2016
Posts: 876
|
Quote:
Originally Posted by Breeder
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.
|
|
|
06-22-2019, 11:43 AM
|
#59
|
Human being with feelings
Join Date: Dec 2016
Posts: 876
|
Quote:
Originally Posted by Breeder
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.
|
|
|
06-22-2019, 03:54 PM
|
#60
|
Human being with feelings
Join Date: Nov 2010
Posts: 2,436
|
Quote:
Originally Posted by srdmusic
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
|
|
|
06-23-2019, 03:13 AM
|
#61
|
Human being with feelings
Join Date: Oct 2015
Posts: 739
|
Quote:
Originally Posted by srdmusic
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.
|
|
|
06-23-2019, 05:14 AM
|
#62
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
Quote:
Originally Posted by mccrabney
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
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.
|
|
|
06-23-2019, 05:44 AM
|
#63
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,750
|
Quote:
Originally Posted by juliansader
* 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?
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 04:24 AM.
|