Reapeaks causing GUI lags at certain zoom levels

Can someone verify?

I can't be sure but I think this problem might be related to a problem that Soli Deo Gloria and I were having in the Midi Editor.

It's not reapeaks that are the problem, the problem is that at a certain zoom level it switches to reading a copy of the underlying video file to get audio information, and that ends up slow (because it's coming from the video container). So maybe we can come up with a way of getting audio more quickly from video files, but I don't know.

Thank you for your replies and thank you Justin for your explanation! This is also happening with audio files, not video only (check my project file in the first post). Wouldn't it make sense to keep some peak stuff in memory when hitting these zoom levels instead of re-reading the data from HDD all the time? This way, the lag would only occur when zooming in and not while editing. What could improve the video situation: use wav as audio codec or completely remove audio from video and put it in as wav-file.

Thanks Justin for the reply. Reaktor Dave might be on to something there. Especially if other types of files are doing it too. Ironically, I don't often need the audio from the video so for me, the first thing would be an option (maybe in source properties) to mute/hide audio from the video track. If I do need the video audio as reference, I could copy the the video to a new track and bounce it to be just audio and hide/mute audio on the actual video item (with a new source properties tick box) which would help a lot. :)

I can safely say that using video stripped of audio has given me no problems of this nature. An "Ignore audio" switch for video items might be a good thing. YOu can always copy the video item and glue the audio to get a copy of that for reference purposes, or use MPEG Steamclip to decode the audio track from MP4 or Quicktimes. That this lag happens with all media that require peak displays however, if there's enough of it on screen, can be a problem though. It may be prudent to think of a strategy to deal with this, as is done with the lazy GUI drawing priority already. Perhaps the most detailed peak files should be drawn in instead of the actual waveform until that is updated with the underlying data.Nobody is likely to mind if the GUI stays responsive.

Solved by unchecking "Hi-res peaks" in Source Properties.

Hi there im not sure if the issue is fixed but this is what i found An old thread from 2014 in cockos forums pointed out that, at curtain zoom, the DAW no longer shows the peak from the peak file generated , but reads directly from the media item, thats why the disk and cpu usage increase a lot. So i checked out the Desired Cache resolution settings : 300 samples/sec That means that smallest length it can display peak from peak files is about 0.003 sec Then i measure that length in arrange view, try zooming in and out And surpisingly , it lagged the most when the length gets too small that it becomes a straight line. Zoom out from that point, it stops lagging, zoom in, lag like crazy My theory is the resolution is not large enough to cover the entire arrange view that contains many tracks and when it reach the point when the DAW has to read directly many tracks at once, lag can occur. but when i zoom in more, less tracks need to be displayed, it stops lagging. So i tried to increase the Desired Cache resolution from 300 samples/sec to 1000 samples/sec Delete the peak files from %temp%/REAPEAK or from the project folder depends on settings It worked No more lagging , smooth zoom in and out. Hope it works for you too