How to design an efficient, responsive Timing-grid

I’m interested in writing an audio editing app, and therefore interested in how the timing grid in modern daws is implemented efficiently so that the UI is responsive and calculations related to the timing grid are quick. My interest includes:

  • Drawing and labeling the grid lines for measures, beats, and ticks
  • Drawing audio waveforms at the correct size and position so the grid lines give an accurate visual of where the waveform is and how long it is etc.
  • Wherever you click in this box, the program easily and quickly calculates your location in measures, beats, ticks, samples, seconds, etc.
  • Doing all of the above with any number of tempo and meter changes in a scrollable, zoomable box containing your tracks, just like you find in the “track window” of virtually all modern DAWs.

I’ve taken a stab at this and I’m finding it quite difficult to achieve the performance level I see in most Daws. Either I calculate everything on the fly, and zooming and scrolling become really slow and cumbersome, or I’ve tried making a precalculated table for every single tick in the project that contains the location in samples and seconds etc. but this means there is a big slow down every time the user changes the tempo or meter since I have to recalculate the table. How do they do all this in modern Daws so that its so effortless and fast?

It’s not that unusual to have two versions of audio tools. The normal one which works in good time but isn’t perfect, and one that does a terrific job if you want to wait for it.

Have you picked a target computer? The software is acceptable if it can work on a computer with this memory and that drive? Sometimes following OS updates and system changes can be a challenge, too. Audacity’s daunting task is working nearly identically on all three major computer types.

I don’t think the developers hang out on the forum very much if that’s what you’re after.


I don’t need an Audacity developer necessarily if someone else has experience with this. I’m a little confused by what you are saying. It really doesn’t seem to me like Sonar, Pro tools, and the like have one grid calculator that sacrifices accuracy for performance and one that is accurate and slow, if thats what you mean, but if you know this is true I’d appreciate elaboration. Sonar’s grid is immediately responsive with all the possible things it can do on the same computer I’m running my app on, so I know I’m missing something. I don’t need someone to post code if they know how it is done and can explain the theory.

I wouldn’t be shocked if Audacity was using the same technique as games use to post an amazing complex background and shift it back and forth rather than render it repeatedly it like they do with some of the characters. I’ll help you wait.