No - I cheated and built an enormous lookup table, for any clock-speed from 0 to 96 & any beat division from 0 to 9! My code for that is super-mega-fugly I had a strong suspicion there had to be a better way, so thanks for the link to those two papers…
umm - well there is an additional complexity…
When you have Bjorklund’s algorithm (or giant lookup table) on hand, there’s still an issue looping sequences of length 11 quintuplets. For a quintuplet loop, the position of read-pointer (in clock-ticks relative to the start of loop) should be:
n-ticks_loop_frame_of_reference = n-ticks_global % (11 / 5 * master_clock_resolution)
so you have to modulo by a fractional number. There’s fundamentally no issue with doing that, but now the rest of the code must behave correctly when the ticks-index of a loop (which a fundamental state variable) is fractional. Think I’m handling this by using (round n-ticks_loop_frame_of_reference) to index things, but suspect that method may actually drop the odd beat. Also, now concatenating sequences becomes a right pain, because the sequences aren’t always an integer-number of clock-ticks long…
Anyway - there are bigger fish to fry on this project than this corner case, but I certainly want to handle it correctly in the end!