Do any DAW authors have advice on time/beat/signature mapping?


#1

As I mentioned in another thread, I’m writing a small/mid sized DAW for a final university project. I’ve implemented what I believe is a reasonably robust marker/automation system, and wanted to be able to modulate tempo and time signature with it.

Do any DAW authors on here have any advice, books or papers I can read on the subject of time/beat/signature mapping in time-varying situations?

The best (and really only) paper I’ve found is on a JavaScript implementation called BPM Timeline, which is fairly math heavy (rather than JavaScript heavy) so I was able to happily write an implementation in C++:

https://smartech.gatech.edu/bitstream/handle/1853/54588/WAC2016-49.pdf

I’m now stumped on how to approach time signature changes - I can map beats to time, even when it’s changing, but I get totally thrown off by the time signature changes, especially if it’s mid-bar…

(manually pinging @jules and @dave96 to channel their wisdom - don’t know of any other DAW authors on here)


CurrentPositionInfo.timeInSamples and tempo changes in ableton live
#2

following.

but also curious what is throwing you off about it? if the pulse never changes (960 ticks per Quarter note, for example), what’s the problem with interpreting a bar of 4/4, then 3/4, then 5/4?
startTickOf54Bar = startTickOf44Bar + ticksInA44Bar + ticksIn34Bar; ?


#3

Yeah, this is one of the hard bits in doing a DAW. It’s fine until you have tempo and time sig changes and ramps, and then it gets very hard to convert between seconds and bars/beats efficiently.

Can’t think of any specific tips… in Tracktion the classes to do this got revised many times over the years and are quite complex. But they do have to deal with time-warping audio clips to fit tempo ramps too, which you can probably avoid in a simple DAW.


#4

Most DAWs these days seem to use tempo only to determine the time <-> beats mapping. The time signatures then just essentially tell you where to place bar/beat lines.

The denominator tells you how often to place a beat line where 4 is every beat. (So n/8 would be two beat lines per beat etc.). (You might also want to scale your metronome so that n/8 ticks twice as fast as n/4).

The numerator the tells you how many beat lines there are in a bar.


There’s then lots of optimisations you can do which you may need to employ depending if you’re allowing curves or not etc. (If you are, you might want to create a flattened version so you can use linear interpolation to lookup beats rather than bezier calculations).

The main useful thing though is to create an iterator with a position in the ramp so that you don’t have to iterate the whole sequence to convert between time <-> beats.


#5

Thanks for the insight/replies!

I have an intermediate knowledge of music theory, so I know how time signatures work when writing/performing music - the scary bits for me are the math when developing the time/beat mappings. I’m glad to know I’m not alone.

I did some more thinking and experimenting with DAWs last night and this morning. My DAW is based on what I believe are the best behaviors exhibited by Logic, Live, and Tracktion, both in UX and under the hood (looking at project formats, data model organization, etc.).

Working some math out by hand and looking at how these DAWs behave, it’s interesting to see that tempo seems to always be in terms of quarter notes - so in 6/8 time the DAW counts like it’s running at the same tempo in 3/4 time. It makes sense since in sheet music BPM is usually denoted by “♩= 120” or similar.

Additionally, it’s very interesting that some DAWs only allow time signature changes on whole bars (Logic), while others only on whole beats (Tracktion), and some allow the nightmare situation of changing at any point (Live). Logic’s approach is the most “musically” correct (I believe in sheet music there’s no such thing as a half bar - you’d switch to 2/4 time or something), Tracktion is a good compromise between flexibility and ease of implementation, and Live’s approach is just nuts because it seems to require a separate mapping on top of the existing time/tempo mapping.

For now, I’m going with a variable tempo (since it’s already implemented) with a fixed time signature.

Thanks again for the input.