.71 issues and observations

[mark604]

First off, thanks to the developers, .71 seems much better than .69. Version .69 was hogging so much CPU I could not play the demo track with my audio interface even without the VST's I added. Now I can not only play the demo track through my interface, but with the VST's I added as well. It's a major improvement.

While it is using less CPU than before, it is still using significantly more System CPU with my MH 2282+DSP compared to BIA. It doesn't seem to do that with other applications. My speculative theory is that Reaper is grabbing all 18 outputs even though it is only using two of them. If that is the case, or whatever the problem is, it should be fixed.

While I freed up a significant amount of CPU by setting UI update to lazy, and not showing meters in the track control panels, even with a severely reduced update rate, the mixer display uses way too much CPU to use it on my system.

The problem seems to be the meters. They have this fancy background gradient, all these little graphic things, and a preposterous number of bar segments -- more than I've ever seen on any piece of equipment. All of which serves no practical purpose. I don't need a light show :) Having an adjustable range and decay ballistics are nice features, but could we please have the option of simple meters that do not waste so much CPU?? Plain bars with 8-12 segments would be fine.

Speaking of graphics and CPU, do some themes/skins use less CPU than others?? Where can I download other themes/skins for OS X??

Also, "enable tooltips" seems to have no effect. The fields with the track names are blank, and there are some unsightly black boxes in the track control panel.

Thanks again to the developers for the latest update.

[AlbertoMiranda]

OK updated 0.71 again, this time with a fix for text issues on PPC macs.. :)

yeah! yeah!

[Justin]

yeah the meters hogging CPU is a result not of their complexity, but of issues with using cocoa for UI in OS X, I think.. they are very simply drawn (pre-rendered and just blit), and use very little CPU on windows.. anyway a lot of the slowness seems to be drawing text, as well... which was the big optimization between 0.69 and 0.71.

-Justin

[mark604]

yeah the meters hogging CPU is a result not of their complexity, but of issues with using cocoa for UI in OS X, I think.. they are very simply drawn (pre-rendered and just blit), and use very little CPU on windows.. anyway a lot of the slowness seems to be drawing text, as well... which was the big optimization between 0.69 and 0.71.

So considering these issues with using Cocoa for UI, wouldn't meters with fewer segments use less CPU?? There is no practical reason to have that much resolution, and "chunkier" meters might even be easier to read.

Anyway, I'll download .71 again, and see if it fixes the text problems.

[Justin]

So considering these issues with using Cocoa for UI, wouldn't meters with fewer segments use less CPU??

Wouldnt really get us that much.. seems that just refreshing ANYTHING chews cpu on it.. looking at ways to optimize that tho.. Unless we made it so low resolution that they didnt update very often, but I dont think that'd be very useful...

[mark604]

Wouldnt really get us that much.. seems that just refreshing ANYTHING chews cpu on it.. looking at ways to optimize that tho.. Unless we made it so low resolution that they didnt update very often, but I dont think that'd be very useful...

Thank you, I'm glad to hear you are looking into it. Please, correct me if I'm wrong, but it seems that there are two things that effect how often the meters have to be "redrawn" -- the update rate and the meter resolution (the number of bar segments).

Having a preference for the update rate is good. Changing it from 30Hz to 15Hz did reduce the CPU load, but lowering it too much results in undesirably jerky meters.

By reducing the number of bar segments, small changes in signal amplitude would be ignored, which would significantly reduce the number of redraws. Looking at the meters on some the gear around me, I see a mixer with 12 LED's, and an audio interface with 10 LED's. My Lexicon PCM-80's only have five LED's. There is no practical reason for the massive number of bar segments that Reaper currently uses. It doesn't tell me any sort of useful information. Like I said, 8-12 segments is fine.

While I'm sure some people are impressed by the gee whiz factor, if they gave it some thought they would likely prefer being able to run more tracks and plug-ins. Meters can only tell you three things: 1) a signal is too hot, 2) a signal is too low, and 3) a visual reminder of which channel is which.

While I admit I know very little about application programming, the the meters in other multi-track software I use (eg. Logic, Numerology, MIO Console) do not seem to chew as much CPU as Reaper. The way it is now, I can't play the demo track with the mixer panel open.

As always, your consideration is appreciated.