Hello, I am tweaking a couple of timers and such in the source code to increase the UI framerate for my build. A gentleman brought to my attention that the wave view in the audio region view does not update in real time but shows a ghost until every 2.6ish seconds (for me). Every other timer tweak has been pretty simple and I have a lot of the program and even my LV2 plugins running very nice and smoothly but the wave view updates have me stumped. Is there some sort of humongous buffer that needs filled before it can be shown? I have tried overriding behavior and forcing pending_peak_data->show() but that didn’t accomplish what I was trying.
Ardour doesn’t use timers for exposure. The Editor and Mixer redraws as fast as possible at default display priority. It can however be slowed down by plugins using high priority times to redraw.
Unless you mean the red record-region when recording?
Yeah. That’s what i’m talking about. Here is a link to a post someone made with a video of what I mean.
We only update once data has been written to disk. We are attempting to show you what has been immutably (hopefully) captured, rather than keep up with real time.
Other DAWs are just keeping with real time, regardless of whether the data is on disk yet or not.
When that (probably) red box advances, you’re supposed to feel “ah good, that’s now on my disk system”.
7 Likes
Thank you! I will let the gentlemen know that this is the reason for that. That makes great sense. I also let the individual who brought this to my attention know as well that he can use an ace inline scope to show the wave shape while monitoring already.
I am interested in this reply. When you say the editor and mixer redraw as fast as possible do you mean specifically up to the fps timer set in timers.cc? I had to modify that from its default 40ms to make my ui run at a more fluid speed. Ardour has never ran at more than 25fps for me usually before. If you or Paul could give me a quick word of direction I may be able to make it show waves faintly as they are recorded and then normally as they are written to disk. No worries if there is no interest in this. Love y’alls DAW, it being open source makes it so much more fun for me to work with than Bitwig and even Reaper.
We do not want recorded waveforms showing before the data is on disk. Partly because it’s of dubious utility, partly because you can already live waveforms on the recorder page, and partly because this is much, much more complex than changing a timer.
That timer is only used for the clocks.
Drawing is done from the main event-loop, not initiated by a timer, and largely depends on the underlying graphics and event system (X11, quartz, HWND). When a rectangle on screen needs to be redrawn (because something changed), that rectangle is invalidated (the OS graphics layer is is informed).
Ardour then waits for a expose event from the OS graphics layer, which calls back into Ardour to draw that rectangle on screen.
Sorry to continue this conversation about the timers here where it’s not entirely related to the title of the topic but I realized that I was mistaken about which value I changed that effected the ui fluidity (specifically in meters and the playhead). The value given to the super_rapid timer in the UITimers constructor seemed to be what made the difference there. If this is not supposed to effect update rate of UI elements then maybe there’s something up with how my desktop environment handles XWayland windows and it’s not giving the expose call as many times as I would think it should.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.