Scroll View Bug

When using the Scroll View Playback feature, it only stays centered if you are in Waveform mode. But if you want to use the Spectrum or Loudness view, the cursor does not stay centered. View Follows Cursor works fine, but not the Scroll View. :cry:

Normal: these displays are too slow to draw to be scrolled.

Yeah I dunno about that one. I can manually scroll / flip through the track in spectrum view very fast without any kind of redrawing taking place. Plus I’m sure it is all pre-rendered on load and then displayed from RAM or DISK to save time and processing power.

I don’t believe it’s pre-rendered. You only have to zoom in or change other display parameters to see it spending time re-rendering the display; or just jump around in a 90-minute long file.

Paul

You probably didn’t know this, but PG is the developer of WL, so if anyone knows, it’s him…

If your computer spends “time” re-rendering the display in a pre-rendered wave file. There are some new solutions you should perhaps look into. :laughing:

Perhaps you miss-understand what I am experiencing. I can manually scroll the context of the audio file in the spectrum view with zero lag or “redraw time” the feature is simply malfunctioning. :unamused:

Once again how can this be accurate, if I can manually scroll through the spectrum view without any lag, or redraw?

In all depends on the number of samples displayed. If the window displays many samples, you won’t be able to scroll even manually with a refresh rate of eg .20 times per second, like the play scroll tries to achieve.

That’s ridiculous. The spectrum view needs recalculating every time you change the zoom level, for instance. Caching even one whole file at one zoom might be a big deal (I work with files two hours long, not just 5 minute tracks, for instance), and every zoom would require recalculating the whole thing - taking far more computer power than just doing the minimum necessary when it’s called for.

As computers continue to get faster, this problem will reduce, and one day it will be gone …

Paul

Modern Digital Computers are already as fast as they are going to get, next step will be quantum interfaces to digital computers or hybrids, then full QMC. I can play some of the worlds best high fidelity real life simulations on my computer with a GTX980, with out a hitch. But rendering a spectrograph waveform in real-time is somehow out of the realm of possibilities. Get real man. This software just doesn’t live up to its potential. Harnessing the power of the GPU will make this process a breeze, and a non-issue. Basically just lazy coders who don’t want to delve into direct x programming or open Gl features. And don’t try to tell me my Skylake processor can’t handle rendering a real-time spectrograph of a 2 or even 5 hour file. When I can run full first person simulations while watching a movie on the other screen, while downloading something else, and hosting a virtual machine, all at the same time.

First of all, If I can manually scroll tracks (~9-12 minutes long) with frames of 30-60fps without a problem, why is this auto-scroll option forcibly disabled?

“many samples”… I mean OK… sure the way the program is right now, you’re probably right. But this can easily be fixed by sending the process(graphical rendering) to the GPU and harness it’s potential. Even modern CPUs can easily crank out the calculations needed for such real-time functionality. And if my computer is powerful enough that I can scroll manually through my tracks without a problem, why is this functionality disabled? If it’s an issue for slower computers or people who master 2-3 hour long mixes then it should stop scrolling or display a message saying the computer cannot handle the request. Then the user can switch to regular mode or it could auto-switch.

It would be silly to say that this is in the realm of impossibility when there are other software and hardware solutions that achieve this result (iZotope). :ugeek:

Nothing is disabled and there certainly is no bug. Maybe it would be possible, but apparently you are the first one to have a problem with it - how is your workflow so different that a scrolling spectrum view is necessary? Personally, I’d prefer all resources in coding WL to go to audio related enhancements and not pretty scrolling pictures.

Yes it would be possible to put more CPU to display real-time spectrum… But in WaveLab, the CPU usage priority is given to real-time plugin processing, not to graphics (except the real time meters). Displaying a continuous spectrum view on a large display would consume CPU needed by the plugins, and this would result in playback glitches.

An approach which the overwhelming body of professional users would surely and completely support.