|
|
|
05-18-2016, 08:27 PM
|
#1
|
Human being with feelings
Join Date: Sep 2012
Location: Chiang Mai, Thailand
Posts: 248
|
Undo very slow, even for simple actions like slice and move item
Undo very slow, even for simple actions like slice and move item. It's slow even on a fast system. I've tried reducing undo memory to see if that would help, but it didn't really do anything.
Reaper 5.20 x64, win10
Session can be downloaded here: https://www.dropbox.com/s/73l9q6jp82..._undo.rpp?dl=0
__________________
Win10 x64, i3930k, 32GB ram
Audio Post | Music Production | Recording Studio | Voice Over
teeramusic.com - Chiang Mai, Thailand
|
|
|
05-18-2016, 11:48 PM
|
#2
|
Human being with feelings
Join Date: Dec 2014
Posts: 538
|
Hi teeramusic. I looked at your project and sure enough, it has a very slow undo. And that's without having any of the plugins or media files available. And with a brand new undo file.
When I did a simple split, then did an undo, it took about 6 seconds. Ouch.
But I notice that when the undo finally happens, the screen does a strange redraw, like it's struggling.
There aren't a lot of tracks, but the project is over 36 minutes. And there seem to be project is over 36 minutes. You seem to have a relatively large number of items, many with take fx. That seems atypical, but I don't know what that all means as far as your problem goes.
Not much help, but at least now you know (if you didn't already) that it's happening on a different setup. Reaper 5.20, Win 10/32.
Have you tried simplifying the project to narrow it down?
|
|
|
05-19-2016, 03:24 AM
|
#3
|
Human being with feelings
Join Date: Sep 2012
Location: Chiang Mai, Thailand
Posts: 248
|
So I tried removing all my 608 instances of item FX and sure enough, things are snappy again. I'm editing audio books and I kind of need them for my workflow. My current workaround is to just drag things out again, but that's not ideal. I've tried to use different save undo state options, but nothing seems to help, including offlining the plugins. It would be great if the devs could have a look at this and make everything snappy regardless of number of plugins!
__________________
Win10 x64, i3930k, 32GB ram
Audio Post | Music Production | Recording Studio | Voice Over
teeramusic.com - Chiang Mai, Thailand
|
|
|
05-19-2016, 05:04 AM
|
#4
|
Human being with feelings
Join Date: Jul 2006
Posts: 12,480
|
Confirmed (5.20 x64).
Maybe it helps if you disable "Save state as VSTbank" for these plugins (rightclick options in FX browser). Most plugins don't need this. Here only TX16Wx needs it for example.
Save the project and test again ...
|
|
|
05-19-2016, 06:10 PM
|
#5
|
Human being with feelings
Join Date: Sep 2012
Location: Chiang Mai, Thailand
Posts: 248
|
Quote:
Originally Posted by Dstruct
Confirmed (5.20 x64).
Maybe it helps if you disable "Save state as VSTbank" for these plugins (rightclick options in FX browser). Most plugins don't need this. Here only TX16Wx needs it for example.
Save the project and test again ...
|
Yea, already tried that, doesn't help.
The only thing that seems to work at this point is to delete them or live with them.
__________________
Win10 x64, i3930k, 32GB ram
Audio Post | Music Production | Recording Studio | Voice Over
teeramusic.com - Chiang Mai, Thailand
Last edited by teeramusic; 05-19-2016 at 06:31 PM.
|
|
|
05-19-2016, 10:42 PM
|
#6
|
Human being with feelings
Join Date: Feb 2016
Location: Vancouver
Posts: 10
|
A workaround for audio books might be to have chapters in sub projects so that your active fx instances are limited to one chapter at a time?
|
|
|
05-20-2016, 04:54 AM
|
#7
|
Human being with feelings
Join Date: Jul 2006
Posts: 12,480
|
Yeah, subprojects might be the key.
|
|
|
05-20-2016, 05:05 AM
|
#8
|
Human being with feelings
Join Date: Nov 2009
Location: UK
Posts: 669
|
I think I know why it is doing this.
The state chunk blobs for the FX you are using are ridiculously massive. Now multiply this by the number of instances.
I use a lot of item FX but don't get this problem. But these are more typical FX like EQ, compression, reverb etc.
It is specific to the FX you are using. They store crazy amounts of data in the reaper project. Look at these FX datas in the RPP...
I think these FX are designed to be used destructively or pre-rendered. They don't seem to be have designed with many running instances in mind.
It may be possible for cockos to find a workaround for FX with large state data, but for now, you'll have to move them to subprojects, so they are effectively pre-rendered. You could also 'glue' but that would be destructive.
Just to give you an idea what a reasonable FX data chunk is like. This is ReaFir.
But this is Izotope Denoiser!
Last edited by mrlimbic; 05-20-2016 at 08:49 AM.
|
|
|
05-21-2016, 10:11 PM
|
#9
|
Human being with feelings
Join Date: Sep 2012
Location: Chiang Mai, Thailand
Posts: 248
|
Quote:
Originally Posted by mrlimbic
I think I know why it is doing this.
The state chunk blobs for the FX you are using are ridiculously massive. Now multiply this by the number of instances.
I use a lot of item FX but don't get this problem. But these are more typical FX like EQ, compression, reverb etc.
It is specific to the FX you are using. They store crazy amounts of data in the reaper project. Look at these FX datas in the RPP...
I think these FX are designed to be used destructively or pre-rendered. They don't seem to be have designed with many running instances in mind.
It may be possible for cockos to find a workaround for FX with large state data, but for now, you'll have to move them to subprojects, so they are effectively pre-rendered. You could also 'glue' but that would be destructive.
Just to give you an idea what a reasonable FX data chunk is like. This is ReaFir.
But this is Izotope Denoiser!
|
The FX is deBreath. But I've already tried save minimal undo state? The sub-project is a good idea for a workaround. But I think maybe the undo system can still be more efficient anyway?
__________________
Win10 x64, i3930k, 32GB ram
Audio Post | Music Production | Recording Studio | Voice Over
teeramusic.com - Chiang Mai, Thailand
|
|
|
05-22-2016, 02:32 AM
|
#10
|
Human being with feelings
Join Date: Nov 2009
Location: UK
Posts: 669
|
Quote:
Originally Posted by teeramusic
The FX is deBreath. But I've already tried save minimal undo state? The sub-project is a good idea for a workaround. But I think maybe the undo system can still be more efficient anyway?
|
Cockos may be able to do some clever workaround for FX with very large data chunks like caching things so don't need to update them. It's not the audio performance that is issue - it is data management. I don't have those FX installed but get same lag problem with your RPP.
But I also think some effects are just not really designed with hundreds of instances in mind, so won't work well as item FX. It may be interesting to see what happens in another DAW that supports item FX.
For these effects, you could also do de-noising in an external editor, that will then come back in as a new take on the same item, if you use "open item copies in XXX".
Last edited by mrlimbic; 05-22-2016 at 04:08 AM.
|
|
|
05-22-2016, 04:12 AM
|
#11
|
Human being with feelings
Join Date: Jun 2015
Posts: 685
|
Quote:
Originally Posted by mrlimbic
I think I know why it is doing this.
The state chunk blobs for the FX you are using are ridiculously massive. Now multiply this by the number of instances.
|
I think you hit the nail on the head. I went through a couple of projects' undo histories and noticed that some of the plugins (mainly those that have a LOT of parameters) create gargantuan undo state chunks.
Some of those aren't even very apparent culprits to cause project slow-down; like the innocent looking NoteMapper by CodeFN42. But inserting just one instance adds a one MEGABYTE state chunk into the undo history.
Using the "save minimal undo states" option for these kinds of plugins helps with this issue, but with the obvious drawback that you'll not be able to undo small changes in the plugin parameters.
I think it would be a huge performance improvement for large projects, if it could be figured out how to save the undo chunk for these parameter-loaden plugins so that only the affected parameters are written into the file. I'm not sure if it's even possible though.
|
|
|
05-22-2016, 04:35 AM
|
#12
|
Human being with feelings
Join Date: Jun 2015
Posts: 685
|
Another thing I noticed: In an old project I can't seem to be able to get rid of the state chunks of at least some of these plugins. Even if I delete all the instances in the project, delete the undo file and empty the undo history, the chunks still show up in the file after I save the project again. Works fine when tested in a new project. Weird.
|
|
|
05-22-2016, 04:38 AM
|
#13
|
Human being with feelings
Join Date: Nov 2009
Location: UK
Posts: 669
|
Quote:
Originally Posted by Sju
Another thing I noticed: I can't seem to be able to get rid of the state chunks of at least some of these plugins. Even if I delete all the instances in the project, delete the undo file and empty the undo history, the chunks still show up in the file after I save the project again. Weird.
|
That sounds like it could be a bug. Where are they in the RPP?
|
|
|
05-22-2016, 04:49 AM
|
#14
|
Human being with feelings
Join Date: Jun 2015
Posts: 685
|
Quote:
Originally Posted by mrlimbic
That sounds like it could be a bug. Where are they in the RPP?
|
Yeah actually, some of these chunks were caused by SWS snapshots I had saved earlier and then forgotten about. There are still a few left, and I think these might be frozen FX, that'd explain why they don't show up in the project bay. False alarm.
PS. it's a fucking blessing that the project/undo files are saved in a readable format.
|
|
|
05-23-2016, 03:18 AM
|
#15
|
Human being with feelings
Join Date: Sep 2012
Location: Chiang Mai, Thailand
Posts: 248
|
Why should the undo point for item move have anything to do with item fx state data? Shouldn't reaper simply move the item back to where it was? And if there is something to do with it, why should it affect all 600 instances instead of the FX on the item that got moved?
The 600 instances are waves debreath with 5 faders and three buttons. If I enable minimum undo state, shouldn't it only save those 8 parameters?
__________________
Win10 x64, i3930k, 32GB ram
Audio Post | Music Production | Recording Studio | Voice Over
teeramusic.com - Chiang Mai, Thailand
|
|
|
06-02-2016, 08:55 AM
|
#16
|
Human being with feelings
Join Date: Nov 2009
Location: UK
Posts: 669
|
Quote:
Originally Posted by teeramusic
Why should the undo point for item move have anything to do with item fx state data? Shouldn't reaper simply move the item back to where it was? And if there is something to do with it, why should it affect all 600 instances instead of the FX on the item that got moved?
The 600 instances are waves debreath with 5 faders and three buttons. If I enable minimum undo state, shouldn't it only save those 8 parameters?
|
Yes. The plugin is probably dumping lots of wasteful stuff in there. That's enough data for 50,000 parameters, not just 8!
We should see if Justin can find some kind of work around. My guess is that REAPER is just trusting the plugin to serialize efficiently. It will just query the plugin to request it's state.
It may be possible for reaper to add code to stop trusting plugins that create crazy amounts of wasteful data.
Did you report this as a bug yet, or shall I? Well... more of a required workaround than a bug. I suspect this is not reaper creating that amount of data.
|
|
|
06-02-2016, 03:56 PM
|
#17
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,721
|
IMO, I don't think it's REAPER's fault that there is slowness dealing with state on most plug-ins -- plug-ins can store considerable state and still be fast, as long as they generate/parse it quickly. I've seen some plug-ins in the past that have very very complex and heavyweight state loading/saving, often using (particularly slow) public-key encryption as a form of copy protection.
|
|
|
06-02-2016, 04:04 PM
|
#18
|
Human being with feelings
Join Date: Nov 2009
Location: UK
Posts: 669
|
Quote:
Originally Posted by Justin
IMO, I don't think it's REAPER's fault that there is slowness dealing with state on most plug-ins -- plug-ins can store considerable state and still be fast, as long as they generate/parse it quickly. I've seen some plug-ins in the past that have very very complex and heavyweight state loading/saving, often using (particularly slow) public-key encryption as a form of copy protection.
|
So what is s creating strange undo/redo delays with big FX? Is there any kind of workaround that can be done with these kinds of plugin that produce unnecessarily huge data. They seem to slow reaper down with redo/undo etc. Could you cache stuff maybe?
PS I tried his project and yes there is massive delays even when I don't have the same plugins installed. Is it some other problem? It takes many seconds to undo/redo.
Last edited by mrlimbic; 06-02-2016 at 04:30 PM.
|
|
|
06-03-2016, 06:20 AM
|
#19
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,721
|
I'd recommend not using plug-ins per item when doing heavy editing. At least, not for all but the most lightweight plug-ins. That project has 600+ instances of Waves Debreath, whose configuration state isn't too high, but still takes a good amount of time to instantiate...
Also: if you don't have the plug-in installed, it still takes a while as it tries to load it 600+ times on undo, ugh.
|
|
|
06-03-2016, 07:35 AM
|
#20
|
Human being with feelings
Join Date: Nov 2009
Location: UK
Posts: 669
|
Quote:
Originally Posted by Justin
I'd recommend not using plug-ins per item when doing heavy editing. At least, not for all but the most lightweight plug-ins.
|
For post production, rather than music, item FX often make a lot more sense than track FX, as the material is short, one off & very inconsistent. Otherwise you would end up with thousands of tracks, one for each sound effect or tiny piece of dialogue. Location dialogue varies massively with each shot being recorded from different angle, different distance, under different noise conditions. Music is a much more consistent well controlled scenario.
I'd say I use 90% item FX vs 10% track FX.
However, I haven't had this slow undo/redo problem myself because most of the item FX I use seem to all be pretty lightweight.
The best workaround for now seems to be to move any heavy item FX to subprojects so it is pre-rendered.
THANKS FOR SUBPROJECTS JUSTIN. It really is an amazing killer feature.
|
|
|
06-11-2016, 09:34 AM
|
#21
|
Human being with feelings
Join Date: Sep 2012
Location: Chiang Mai, Thailand
Posts: 248
|
So I've moved away from debreath completely, as I found that it was faster to use remove silence and fix what was not perfect. I agree that in post it's very common to have a lot of item FX.
Also (while we're still on this thread) when I undo a media item move or undo a track re-order, a bunch of my samplers will (sometimes) reload their samples. How come? Isn't there a more efficient way to do this without breaking anything?
__________________
Win10 x64, i3930k, 32GB ram
Audio Post | Music Production | Recording Studio | Voice Over
teeramusic.com - Chiang Mai, Thailand
|
|
|
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 09:58 PM.
|