Reaper uses 10x cpu when zoomed in past a certain point

[Serenity]

When I zoom in to do some precision work reaper comes to a stand still.

When I am zoomed out so that I can see more than 1 bar at around 80bpm, reaper works fine and uses about 2% cpu, when I zoom in past 1 bar, reaper starts using about 20-30% cpu and becomes very unresponsive.

I have a lot of multi-channel items and tracks(> 100) but only a few(< 5) are visible when I am working on them.


Is this a bug or a settings issue? I can't understand why zooming in would cause reaper to use so much cpu.

Zoom Level -->
          |---------
          |
          |
----------|
          *
          ^ At some point reaper just craps out and it's not like I'm zoomed in 100x.

It is very annoying to work like that because it makes it hard to do precision work.

Any ideas? I have a decent computer, I doubt it is that, gfx drivers, etc.... Again, reaper works fine except right when it crosses that threshold.



-----
Note: Having reaper show only the waveform for the selected track fixes the overload problem... but of course I would like it to show all wave forms.

Is reaper displaying all the waveforms even for the ones out of view? Seems like it!!! This is a performance issue with reaper if so!

Reaper should only show the peaks for waveforms that are visible. Can we, at the very least, get an option for this?

[serr]

Someone correct me if I'm wrong but I believe the peak overview files are only useful to a certain zoom resolution. That means when you zoom in closer than the peak overviews can support, Reaper needs to generate the peak display directly from the audio files. This uses processing power.

So, if you are already pushing your system this could bite you.

[Serenity]

If that's the case, reaper still seems to be way more inefficient than it needs to be.

When I use those settings such as "Only display peaks for selected tracks", and I select all the tracks visible(usually about 4-5), reaper responds much better. If I disable that setting, reaper craps out....

The only difference? Reaper is very slow when the setting is disabled AND I have to always select the tracks I want to see. I'm sure reaper can easily figure out which tracks are visible and "select" them for me automatically(not actually select, but basically turn on waveform display for those tracks).

[EpicSounds]

What's the file format you're using? Is reaper realtime resampling?

[serr]

Are you reporting "total CPU" or "RT CPU" use? RT CPU use shows the big audio thread and is usually more useful as this thread almost always maxes out well before total CPU use on a multi-core system.

What CPU use do you have going on in one of your larger projects (with normal zoom levels)? Are you already pushing 80% or more RT CPU use? And then zooming pushes it over the edge?

If you instead meant that you have only RT CPU use of 30% and Reaper is becoming unresponsive at that level, then something else is going very wrong. (Yes, the added processing is adding up and crossing a line but there's a more serious root cause issue.)

General comment: Reaper requires proper use of the anticipative fx processing and number of audio threads features when using 3rd party vst or au plugins. Misbehavior is usually always plugin based. This can often be ignored in small projects, but when you have over 100 tracks and 100 plugins running you need to start paying attention to the preference settings. And possibly learn the limitations of any "fussy" plugins you might have.

[Serenity]

None of that matters. Regardless of what cpu I'm using, gfx card, plugins, etc, if reaper works great when I use the option "only selected tracks show peaks" and select 15 tracks then it shouldn't be hard to optimize reaper to not require me to select the tracks to get improved performance.

Obviously if I upgrade my computer it will do a better job, but that still doesn't change the fact that reaper seems to be doing a lot of work that it doesn't have to do... which means if reaper is fixed it will be better on all computers.

[serr]

Originally Posted by Serenity

None of that matters.

That's rather cavalier. But OK, good luck then.

[EpicSounds]

Originally Posted by Serenity

Obviously if I upgrade my computer it will do a better job, but that still doesn't change the fact that reaper seems to be doing a lot of work that it doesn't have to do... which means if reaper is fixed it will be better on all computers.

You haven't listed any details about your system to help Cockos narrow down the issue.

Did you read the post pinned at the top of this subforum?
How to report bugs

[ivansc]

Oh - and welcome to the Reaper forums, Serenity!

New blood is always appreciated here.

You will find us for the most part a very friendly and helpful bunch.

[Serenity]

Originally Posted by serr

That's rather cavalier. But OK, good luck then.

I just don't feel like sitting on the phone for an hour with some guy telling me I need to clear out my internet explorer cache because my car won't start. Sorry. Of course, it's my fault for calling the isp and asking why my car won't start ;/

The logic is very simple:

Reaper works better when X is set. But this requires one to manually do work Y. Reaper can automatically do Y if they add the capability. I'd rather have a combine working the fields than doing it myself by hand. Is that too much to ask? I know, I'm just lazy!

[Justin]

Originally Posted by EpicSounds

What's the file format you're using?

I'd be curious too, often cpu use when zoomed far in is the result of compressed files (wavpack or ogg etc, since at a certain point it has to decode them to display the waveform).

[Serenity]

I do use wavpack 32FP and the files are multi-channel.

I am curious as to why reaper seemingly works fine until one increment of the wheel mouse causes it to become very laggy.

As far as I can tell the waveform does not change any, like a progressive jpeg.

Reaper is obviously doing something but as far as I can tell, nothing actually changes except, of course, I'm more zoomed in. Obviously more points per beat are having to be calculated, but also less points are in view(fewer beats, since I zoomed in).

All I can really say, is, record a bunch of multi-channel audio items, a hundred tracks worth or so, several minutes each, then try it. Use Wavpack if you think that is the problem.

I guess you could just dump a bunch of songs into reaper, one track per song, then change the format to wavpack, and save. Then try zooming in.

It's just very annoying to have to do some precision work to zoom in and reaper working very well, then zoom in one notch more and reaper come to a near halt. (and if playback is happening, it can cause reaper to lock up)

Again, obviously a faster cpu(2.5ghz 4core) would make things better, but I don't think that addresses the problem.

Justin, can you explain to me why the performance of reaper would depend on the zoom? If peaks are calculated for quality based on zoom, can something be done such as caching, only calculate for items in view, etc?

[serr]

Originally Posted by Serenity

I just don't feel like sitting on the phone for an hour with some guy telling me I need to clear out my internet explorer cache because my car won't start. Sorry. Of course, it's my fault for calling the isp and asking why my car won't start ;/

The logic is very simple:

Reaper works better when X is set. But this requires one to manually do work Y. Reaper can automatically do Y if they add the capability. I'd rather have a combine working the fields than doing it myself by hand. Is that too much to ask? I know, I'm just lazy!

You got to a point with Reaper where you crossed the line with processing abilities. You identified the point in zooming where Reaper reads directly from audio files as that line. (Maybe you didn't know close in zooming took more processing resources. Now you do.)

You can complain and ask for Reaper to be improved. We'll see how that goes.

You can also take the advice on looking into Reaper's optimization options in preferences and very likely refine your system so you don't cross the line with your workflow.

[EricM]

Never had the issue with audio (but i seldom use compressed files),
I do however always experience a similar problem when working with
a video file (compressed, naturally) with or without audio present.

The only solution for that case is I always have to hide a track that
contains a video, otherwise I get laggy behavior when navigating on
high zoom levels.

I guess these could well be related problems.

e

[Serenity]

@serr: If that is the case, I'd rather at least have a setting to when reaper reads from the file directly. If that is truly the reason(It would be nice to be confirmed), there are two simple solutions reaper can implement:

1. Have an option to set what level of zoom reads from the file. I only need 1 or 2 more wheel mouse increments to get to the level I'm at. Reaper seemed to choose the most inconvenient point for me to decide to read from the files. If I can tweek it then I can optimize it myself for my computer and situation.

2. Load the audio files in memory directly. At the very least, allow me to force which tracks are "cached" in memory. I'd probably still need option one if reaper is going to load out-of-view waveforms.

If I have 64GB of memory I want reaper to use as much of it as it can it can for optimal performance(within reason, or at least let me some control of what is loaded). I have 8GB of mem, 6GB available, and the project is 8GB in size, all wav data(no samplers). Reaper uses about 1GB peak. Why did I buy 8GB if reaper won't use more? What would be the point of upgrading to 64GB if reaper still will use only 1GB?


--

If that really is the problem though, I'm willing to get an SSD to solve it.

@Eric: Probably related. I essentially have to do similar things but it's like having 100 video tracks instead of one.

[EpicSounds]

Originally Posted by Serenity

@serr: If that is the case, I'd rather at least have a setting to when reaper reads from the file directly. If that is truly the reason(It would be nice to be confirmed)

Justin confirmed

Originally Posted by Justin

often cpu use when zoomed far in is the result of compressed files (wavpack or ogg etc, since at a certain point it has to decode them to display the waveform).

Can you use wav instead of wavpack?

If you want better performance, but simultaneously want to live dangerously. You can create a RAM Disk to run the session from. The contents of a RAM disk is cleared when restarting the computer.

[serr]

Originally Posted by Serenity

@serr: If that is the case, I'd rather at least have a setting to when reaper reads from the file directly. If that is truly the reason(It would be nice to be confirmed), there are two simple solutions reaper can implement:

1. Have an option to set what level of zoom reads from the file. I only need 1 or 2 more wheel mouse increments to get to the level I'm at. Reaper seemed to choose the most inconvenient point for me to decide to read from the files. If I can tweek it then I can optimize it myself for my computer and situation.

2. Load the audio files in memory directly. At the very least, allow me to force which tracks are "cached" in memory. I'd probably still need option one if reaper is going to load out-of-view waveforms.

If I have 64GB of memory I want reaper to use as much of it as it can it can for optimal performance(within reason, or at least let me some control of what is loaded). I have 8GB of mem, 6GB available, and the project is 8GB in size, all wav data(no samplers). Reaper uses about 1GB peak. Why did I buy 8GB if reaper won't use more? What would be the point of upgrading to 64GB if reaper still will use only 1GB?


--

If that really is the problem though, I'm willing to get an SSD to solve it.

@Eric: Probably related. I essentially have to do similar things but it's like having 100 video tracks instead of one.

Couple things...

All DAWs do "live" zooming when you get close up. The fact that Reaper lets you use compressed audio formats creates the situation where you can push your system over the line.

Myself, I'm just happy to have the convenience of being able to run flac files directly in a DAW in a pinch. I put my current large resource needing projects on one of the SSD's when it's time to get serious mixing as well as run uncompressed wav files. No point being stubborn, especially when we already have more options than ever before.

Ram use... Who started the rumor that you need 120GB of ram to do anything?! When I'm running live sound with Reaper with a 128 sample buffer for near-zero latency, running 36 channels of live inputs and simultaneously recording all the multitrack to disc, I'm using about 2GB ram max. I've got SSL channel strips on all the tracks, delay and verb fx units on fx buses, etc, etc. That all uses under 2GB. When I'm in studio mode with 24/96 audio and 200+ tracks, 200+ plugins, etc, etc - still under 2GB ram use. The 16GB in the i7 just sits there looking impressive or something.

A SSD however is required to do the above (the live sound + recording anyway). This is the item that will give you the biggest bang for the buck in an upgrade.

I still recommend looking into proper 3rd party plugin management like I mentioned earlier. You just might find that you can open up processing headroom and maybe now zoom in on those flac files without lags and have everything you want.

[Serenity]

@serr, again, while you might be correct in your statements, this still does not mean reaper cannot be improved.

If it is "live zooming" that is the issue, coupled with the compressed formats, then reaper can easily implement an option to cache results on "selected tracks", for example.

If that's not good enough, then reaper could simply have an option on the items property to load the file in memory uncompressed. It should be a rather simple implementation but would provide a good performance boost for those that need.

It sounds as if you are arguing that it is ok for reaper to have such issues. I am arguing that reaper can be optimized, probably in a day or two's work. This will benefit all that use reaper. If I go out an buy a super fast computer, sure it will make thing better. But I will be the only one to benefit from it. Other people will still experience problems. Maybe not to the degree I have, but status quo is not a very good argument here.

If reaper is already fully optimized and it's on my end, then it is my fault and my problem to get a better system. If it is on reapers end then it is reapers fault and reapers problem. Of course, if that is the case, I have little recourse except to bitch and complain and spend money upgrading hoping that will push me past the threshold.

[DarkStar]

^^^^
Not quite.

Your best bet is to post a problem project as an attachment, with the steps to take to create the problem, so that the devs (and us) can see what's going on.

How to post attachments

[serr]

Originally Posted by Serenity

@serr, again, while you might be correct in your statements, this still does not mean reaper cannot be improved.

Sure!

Originally Posted by Serenity

If it is "live zooming" that is the issue, coupled with the compressed formats, then reaper can easily implement an option to cache results on "selected tracks", for example.

Well, stop talking and write your custom actions then! Reaper will let you do that right now. (Another thing no other DAW will do.) You're the one who wants to zoom in to nearly the sample level with compressed files.

Originally Posted by Serenity

If that's not good enough, then reaper could simply have an option on the items property to load the file in memory uncompressed. It should be a rather simple implementation but would provide a good performance boost for those that need.

You'd do all that instead of just converting the folder of files back to wav for an important project? That's just silly. Also that's exactly what Reaper is doing with compressed files. Converting them back to wav on the fly. Hence the processing hit.

Originally Posted by Serenity

It sounds as if you are arguing that it is ok for reaper to have such issues. I am arguing that reaper can be optimized

Nope. You'll see me whining about 3rd party plugin efficiency around here. Been going on for a couple months now. Then I'll post suggestions and see what success other people have. Sometimes the responses make me revisit my theories and try new things. Sometimes it pays off.

Personally I think Reaper should not need tweaking until you go over 500 tracks and 500 3rd party vst & au plugins. But that's apparently just me.

Originally Posted by Serenity

probably in a day or two's work.

Haha. Say that to Justin and see what he says.

Originally Posted by Serenity

If reaper is already fully optimized and it's on my end, then it is my fault and my problem to get a better system.

Go after operator error first. Only costs some time. I mean that in the nicest way, I really do. The positive point I'm actually trying to make is there are things you can try for free that don't involve developer input.

[Argitoth]

Originally Posted by Serenity

I do use wavpack 32FP and the files are multi-channel.

that's a red flag for me.

how large is the largest media item in your project?
how many media items total?
how many channels in the item with the most channels?

Another thing you could do to help is take a licecap so we can see the zoom levels and where the cpu spikes.

Edit: According to my google search, one thing you could try is use integer instead of floating point, because integer = less CPU to decode. The down-side is that it has a limited dynamic range, so if you clip, that will be burned in... i think?

[Mr. Data]

Well, integer 32 bits offer only 192 dB dynamic range. Reminds me of an Edison cylinder.

Sorry, couldn't resist.

Just use uncompressed wave files, and when the work is done compress everything (if you want) and then archive your project. Problem solved.

All this arguing about needing to work with a compressed fileformat that on top of it is FP makes me imagine a man, who desperately wants to put a nail into the wall with the wooden end of the hammer, saying the hammer should be improved, 'cos he's got problems, getting the nail in.

Reaper surely has its issues, but I wouldn't put especially this in that list.
It's like in every area of life: If you want to do things your way at all cost, you might have to take the drawbacks.


-Data

[Lawrence]

Originally Posted by serr

All DAWs do "live" zooming when you get close up. The fact that Reaper lets you use compressed audio formats creates the situation where you can push your system over the line.

Myself, I'm just happy to have the convenience of being able to run flac files directly in a DAW in a pinch. I put my current large resource needing projects on one of the SSD's when it's time to get serious mixing as well as run uncompressed wav files. No point being stubborn, especially when we already have more options than ever before.

Well... uh... yeah.

What I was going to say was that I have experienced similar before in other products, where zooming in with compressed files (or some other high demand drawing situation) slows things down noticeably.

Rather than going around in circles, wouldn't it maybe be better to just see if what the OP says is actually true or not? If other workstations that run compressed files on the timeline (I'm sure many do these days) exhibit the same type of behavior?

If they don't ... he has a point. If they do, it is just what it is. I actually stem full projects to FLAC a lot ... so I have lots of full projects with 20-30-40 tracks where all the files are FLAC.

Try some other workstations with the same files that slow Reaper down and see what if anything similar happens. If some other products don't do that or not quite as bad, with the same files, that's a case for optimization no?

[Argitoth]

Originally Posted by Mr. Data

Just use uncompressed wave files

That's not going to solve the problem. As a sample library developer working with tens of thousands of files and gigs of audio at once, I know very well the limitations of REAPER, so I need the OP to say exactly what he's working with. How big, how many files, how many channels per file.

REAPER does need a few fixes when it comes to large files, because it should be able to handle what I throw at it. I know this based on knowing when REAPER fails and succeeds. I don't think these fixes are unreasonable. It's not much of a jump (or not much of a stretch) for REAPER to be able to handle the situations it cannot currently handle. It comes down to caching/RAM, I'm pretty sure. It needs a tweak and possibly more user options.

[Serenity]

Originally Posted by Mr. Data

Well, integer 32 bits offer only 192 dB dynamic range. Reminds me of an Edison cylinder.

All this arguing about needing to work with a compressed fileformat that on top of it is FP makes me imagine a man, who desperately wants to put a nail into the wall with the wooden end of the hammer, saying the hammer should be improved, 'cos he's got problems, getting the nail in.

-Data

No, that is called ignorance and because you believe it is actually an argument proves it.

The wooden end of a hammer is not better than the metal end for hammering in nails in all respects.

But ignoring that there are better ways to put in a nail, which is actually what you are advocating, is just as ignorant as using the wooden end. A nail gun is an improvement over a hammer EXACTLY because someone with have a brain decided there was a better way, NOT because they believed the best way already existed.

Reaper can do a better job, regardless of what you want to believe. It's obviously very easy to think reaper can't do better if you do not know any better. Just keep using your hammer. Maybe one day you'll realize that people that make progress are not bound by caveman logic.

[Argitoth]

Wow, Serenity, thanks for taking the time to argue with forum members rather than actually posting useful information.

[Mr. Data]

Originally Posted by Argitoth

That's not going to solve the problem. As a sample library developer working with tens of thousands of files and gigs of audio at once, I know very well the limitations of REAPER, so I need the OP to say exactly what he's working with. How big, how many files, how many channels per file.

REAPER does need a few fixes when it comes to large files, because it should be able to handle what I throw at it.

No, it hasn't imho, because neither Reaper nor any other software, can handle everything in every situation and THIS situation is quite special. And since one is able to do the same thing in another way (but refuses to do so) I might be right in saying that it's quite unlikely that there will be something done about it. At least not, if Serenity goes on refusing to give detailed and reliable information.

I thought the main problem here is displaying waveforms of numerous extremely zoomed-in files, that are on top of that compressed FP ones. I suspect the size of those files doesn't really matter much in that context since the waveforms are calculated out of what is in ram anyway. But to be able to make those waveforms visible, they have to be decoded first (which isn't Reaper's, but the decoders task). So, if the computer is on heavy duty, decoding files and isn't powerful enough to cope with that fluently, it (imho) would be common sense to let it do the things it has to do one after another, because on top of all that it might have to switch between the tasks of decoding and preparing data for the graphics card back and forth, which means an additional (not necessary) loss of power, because each taskswitch means pushing data of one task onto stack, pulling data from the other task from another stack and certain other administrative things the CPU has to do and so forth. All this costs unnecessary resources.

As I said, Reaper can be made better as any ever men-made thing can. You just have to lurk around the forums to see, what's most wanted and needed.
But, to my experience, If this should be a Reaper issue, Justin will take it as a challenge to solve it asap.

Originally Posted by Serenity

But ignoring that there are better ways to put in a nail, which is actually what you are advocating, is just as ignorant as using the wooden end.

Well, it's quite funny how you try to put my argument into the opposite of what I'm saying and then go on defending to use the wooden end.

Remember: YOU got the problem, not we. You arrogate, that Reaper has to handle your special situation, and at the same time refuse to try every well-meant and helpful proposal or even provide useful and reliable info.

It would btw. be interesting, to hear of an example of other software that does what you need.


-Data

[EpicSounds]

Posting the link again

Help us help you

[Argitoth]

Mr. Data, I am not here to argue.

If I am able to present the problem in a plain way, and have an easy solution, and Justin feels that it would be a good addition to REAPER or a good fix, then it will be solved.

I want Serenity to post details of his situations so I can learn and gather more critical information to doing the above (present the problem and solution). That's it. The fix for this problem may well improve the experience of other situations, so any fix, any problem solved may well be a benefit to the whole.

So stop arguing.

[Mr. Data]

Argitoth, I'm totally on your side, besides

Originally Posted by Argitoth

So stop arguing.

I never will in any circumstance whatsoever let anybody tell me to shut up.
(...well, at least it will have no effect. ).
I hope you got that.
If you can't stand this, put me on your ignore list - problem solved.


-Data

[Fergler]

Mr Data has a good point about a revealed inefficiency of Reaper. Why can't you guys just accept that there is a *possible* problem and conclude that the devs might want to look into it?

Ffs stop overcomplicating things and get on with it

[Serenity]

Originally Posted by Argitoth

Mr. Data, I am not here to argue.

If I am able to present the problem in a plain way, and have an easy solution, and Justin feels that it would be a good addition to REAPER or a good fix, then it will be solved.

I want Serenity to post details of his situations so I can learn and gather more critical information to doing the above (present the problem and solution). That's it. The fix for this problem may well improve the experience of other situations, so any fix, any problem solved may well be a benefit to the whole.

So stop arguing.

I doubt there is very little I could post. I did give details already. I said I use multichannel(>=4, since 2 would be stereo, and reaper doesn't let you create odd multichannels). I said the projects were about 8GB and I didn't use any samples. I also said I didn't zoom in all that much, about half a bar at 80bpm. All the information that you could possible find useful is there. Do you want to know exactly how many tracks I have? Or how many audio items exists? Do you think a specific number will solve the problem? Or can general answers be used? Like, a lot! hundreds! Is that good enough?


What else do you want from me? And an itemized invoice?

[musicbynumbers]

Originally Posted by EricM

Never had the issue with audio (but i seldom use compressed files),
I do however always experience a similar problem when working with
a video file (compressed, naturally) with or without audio present.

The only solution for that case is I always have to hide a track that
contains a video, otherwise I get laggy behavior when navigating on
high zoom levels.

I guess these could well be related problems.

e

This for me too. Only way at the moment is hiding the video track then all is good again

I hope there's a solution for that soon devs (and no preview on videos without audio)

[Mr. Data]

I tried using Reaper with video several times, eg. just to add some samples here and there to a cartoon, but always had problems. Either I couldn't see anything in the video window or aud/vid synchronicity went off (which didn't happen in other software) or Reaper crashed on loading a video file. Maybe I did something wrong, but it didn't work for me. Since it isn't a video editing software anyway (yet ), I went back to Vegas.

Originally Posted by Serenity

Do you want to know exactly how many tracks I have? Or how many audio items exists? Do you think a specific number will solve the problem?

Well, maybe a specific number would not solve the problem, but this would help in combination with technical data about your computer (CPU, num of cores, clock-frequency, HD (speed, size, ex-/internal, SATA/USB) ie. SSD etc., other processes (normally) running at the same time as Reaper - all that helps to nail the issue and I'm sure, I've forgotton a lot of aspects here, others might think of).

-Data

[EricM]

Okay, so here is a little video test project (697.0 KB) you guys can download
(hopefully DEVs too), open it and report back if at that zoom
level the interface lags for about a second everytime you navigate
around the project.

e

[Serenity]

Yes, It lags on mine very similar to my situation. I can zoom very freely(no lag) as long as I don't zoom in more than about 1 bar in the window. Once I get past that, reaper essentially freezes for about a second every half second.

It is probably the same issue in my scenario, except in mine, I don't have that problem in simple projects(it doesn't always do it).

[EricM]

So did anyone apart from Serenity try this project? Please do and report your findings.

e

[EricM]

Anyone?

[EpicSounds]

The OP never even said which OS he's using.

@EricM I tried the project. CPU fluctuates about 1.5% when zooming.
No lag until I duplicated the video 20x for more cpu load. (didn't test with fewer tracks).
Noticeable lag starts when zoomed to to fit 3.1.25. The project at this point is 10% CPU idle and 19% whilst scrolling.

OSX 10.7.5
REAPER 64
iMac - 3.4 GHz i7, 12GB RAM
Project running on system drive, 7200 RPM