Oooh a new section in the forum!
I thought I should honour the occasion in some way so I thought I might share some of the research that I did for the subclocks in the vX. I’ll try and make this make as much sense as possible and include lots of pretty pictures 
So here’s the idea. I want to be able to run a group of clocks, which will be synchronised with each other in some way, but will trigger different numbers of steps per bar, like this:
:|x x x x |x x x x |: 8 steps/2 bars
:|x x x |x x x |: 6 steps/2 bars
The reason behind this is to have a sequencer which will allow the use of polyrhythms, which are widely used in ethnic music and the only way to play breakbeats in their original form (before western notation got involved and the boffins decided to make it fit into their existing timing scheme). If you’re not sure what I mean, find some old “taiko” (sometimes called “daiko”) drums and be introduced to my favourite form of music 
Polyrhythms are enjoying something of a resurgence in some forms of music in the last few years too (especially in industrial electronica and rock), and I suspect that we’ll hear them on the charts before too long :
So, how to go about this? … Most of the time, a sequencer will count down a certain number of MIDI clock ticks before triggering the next step. Because MIDI clock ticks at a rate of 24 ticks per quarter note, for example, If you want 1/4 notes, you wait for 24 ticks between each step. For 1/16th notes, you want 1/4 of that time, so you wait for 6 ticks to pass before triggering the step. For a 1/4 note triplet, you would want to trigger 3 times every 1/4 note, so that’s 3 times every 24 ticks, so 8 ticks. If you want a whole note (one bar long) then you would wait for four 1/4 notes, 96 ticks, to pass between each step.
It may be becoming clear to you now why the number 24ppqn was selected - at 96 ticks per whole note, it makes it simple to find commonly used measures of time in modern music, such as 1/2, 1/3, 1/4, 1/6, 1/8, 1/12, 1/16, 1/32 etc etc etc. If you take 96 (ticks) and divide it by any of those numbers, you will find that you get an integer (no decimal point). Awesome.
So what if I want to hear 5 steps per bar? This is not the same as 5/4 time, which would be 5 of the 24ppqn ticks - I’m talking about 5 steps in a normal 96 tick bar. If we divide 96 by 5, we get 19.2. Houston, we have a problem.
There’s no such thing as 0.2 of a tick, and the countdown to the next step is measured in ticks. 0.2 of a tick is empty space between the ticks themselves. How would we know when to trigger the step?
Now, if we want to hear 5 steps per bar, we could wait for 19 MIDI clocks to tick between each step. But of course this means that after 5 steps, only 95 ticks have passed. This means that the next bar would start one tick before a normal length bar of 96 ticks would. And the next time it would start two ticks too soon, then 3, and 4, and before you know it, the bar is a 1/16th note out of sync with the rest of the song, and getting worse by the moment. No good.
Alternately, we could wait for 20 ticks each step, but then we get the opposite problem, and the same result - it’s out of sync.
The trick here is to remember that music is ALL about fractions (ratios, if you like) and fractions don’t use decimal points, they use a “remainder” or “modulus”. So 1/5 of 96 is 19 with a remainder of 1. The remainder of any combination will be the amount of ‘drift’ in synchronisation explained just above.
So, no problem. All we need to do is tack the remainder onto the end of the bar. So 5 steps will be triggered, each with 19 ticks between them, and when that is over(95 yicks have passed), we wait 1 more tick (the remainder), before starting over. Obviously, it is not perfect, but it is as close as possible with the master clock (24ppqn) that we have. The first note will begin at the correct time, and the notes will be 0.2 of a tick too soon each time, until the last tick, where the remainder is added on, and that note is a little longer (19(normal length)+1(remainder)), to compensate for the others being a little too short. This error of 1 clock tick is not really much, and is pretty much acceptable. Humans have drifted more than this for centuries and nobody complained Yay a solution!
Bzzzt wrong. There are two problems with this idea.
If this 1/5 note clock is started at the same time as a normal 1/4 note clock, then they will both start together and end together. Fine. But if they were started at different times, the remainder may get tacked onto the end of the 5 notes, but that might be played in the middle of a synchronised 4 note bar. In this case, the error is not really increased beyond that described above, so it is still a deviation of 1 tick, as good as we can get…but we should consider…
What if our remainder is bigger? For eg, What if we are talking about 9 steps per bar? (10.6 recurring ticks per step) Now we have 10 ticks per step, for 9 steps, which leaves us with a remainder of 6 ticks. it would look like this:
Step ticks
1 10
2 10
3 10
4 10
6 10
7 10
8 10
9 16! (that’s 10, plus the remainder of 6)
Yuck! Imagine that big long step sitting in the middle of a nice neat 4/4 bar… and the maximum error is now quite large too, because even after two steps there should be 21.333 ticks, we’re already over one whole tick out of sync. after 3 steps, there should be 32 steps but there have only been 30, now we’re two ticks out of sync. And it just get’s worse and worse until we are finally 6 ticks out of sync. Bad.
What we want, is to slowly smooth this remainder out over time. In the chart below, we can see a way of doing this with floating point calculations, just for the purpose of illustration, again using 5 steps per bar. The floating point calculation is on the right hand side. It shows how many ticks would pass to divide the bar up evenly. The next column from the right shows the floating point number rounded to the nearest integer. the ‘ticks’ column shows the number of ticks inbetween those integer figures.
Step ticks FP, rounded ticks (floating point - the ultimate and impossible goal)
1 11* 11 10.6`
2 10 21 21.3`
3 11* 32 32
4 11* 43 42.6`
5 10 53 53.3`
6 11* 64 64
7 11* 75 74.6`
8 10 85 85.3`
9 11* 96 96
Remember that our gap between steps was 10, with a remainder of 6? Notice that sometimes, if we round to the nearest whole number of ticks, we need to add 1 tick to the normal gap of 10 ticks. Notice that in one whole loop, that happens 6 times? That’s our remainder, and if you look at the chart above, you can see that it is not just ‘glued’ onto the end of the bar, but nice and neatly distributed throughout the loop. MMM, pretty.
Now, that is all well and good, but as you may be aware, floating point divisions are very processor intensive. If we calculated the countdown between steps like that, well, it just couldn’t be done .
So my theory was, that the distribution of the remainder, was directly related to the value of the remainder and quotient. And sure enough, it is. I just needed to find a computationally inexpensive method of calculating when to add a tick from the remainder, and when to not - Or looking at it from a floating point perspective, when to round up, and when to round down. And I need to do it by addition and subtraction and maybe multiplication, but definitely not dividing.
So I came up with this method of modulus distribution. I’ll continue with the example of 9 steps per 96 tick bar.
When the clock is first initialised, there is a divide operation. This is the only occasion where a divide is required. This returns the quotient and modulus of the equation. (eg for 9 steps, the quotient is 10 ticks, and the modulus (remainder) is 6 ticks). There is a variable used to count down to the next step, and the trick is, a ‘modulus counter’ variable. Here’s how it is used.
- When the clock is initialised, modulus counter is set to the modulus (6).
…
-
the countdown until the next step is set to the quotient (10)
-
To calculate the length of the next countdown, the modulus (6) is added to the modulus counter (now=12).
-
If the modulus counter (12) is greater than the modulus (6)(it is), then 1 tick is added to the countdown (now=11), and then the quotient (10) is subtracted from the modulus counter (now=2)
-
The countdown is decremented each time a midi clock event is received
-
When the countdown reaches 0, the next step is triggered, and this process is repeated…
- the countdown until the next step is set to the quotient (10)
- To calculate the length of the next countdown, the modulus (6) is added to the modulus counter (now=8).
- If the modulus counter ( 8 ) is greater than the modulus (6)(it is), then 1 tick is added to the countdown (now=11), and then the quotient (10) is subtracted from the modulus counter (now= -2)
- The countdown is decremented each time a midi clock event is received
- When the countdown reaches 0, the next step is triggered, and this process is repeated…
-
the countdown until the next step is set to the quotient (10)
-
To calculate the length of the next countdown, the modulus (6) is added to the modulus counter (now=4).
-
the modulus counter (4) is not greater than the modulus (6), so the countdown is left alone (still = 10), and the modulus counter is left alone (still=4)
-
The countdown is decremented each time a midi clock event is received
-
When the countdown reaches 0, the next step is triggered, and this process is repeated…
And if you can actually make sense of that mess you may have noticed that there is a pattern formed - it goes 11, 11, 10, 11, 11, 10, … Just like the rounded floating point calculations! Yeehah!
This all sounds more complex than it is… it comes down to a matter of a few instructions each time a new step is triggered.
Anyway I promised pretty pictures, and of course I had to test the algorithm out to see how it would work and how accurate it would be, and it’s resulted in a big excel document with a couple of graphs. The first one is a graph of a chart like the one above, with the floating point calculations compared to the vX algorithm. It’s extremely boring, just two straight lines. That’s actually a very good thing, because I don’t think you’d be able to tell them apart without the index:
Boring. But nice to know.
I’ve also graphed the deviation from the perfect result. To make sense of this, if the points ever reached the edge, they would be going beyond a whole tick out of sync, but so long as they are within the circle, we are as accurate as it is possible to be. Points at the center are perfect. But the reason for this type of graph is to demonstrate the rhythmic nature and even spread of the modulus. The end result is a flower. Oh how nice. I have attached the graphs for a 9 step bar over 1 and 4 bars.
The more complex the subclock timing, the more interesting patterns come out of this as the algorithm struggles for perfection. Prime division makes for really interesting neverending flowers, and I included a 63 steps per 15 bar pattern graph just for kicks.
Hope you like the happysnaps and the gory details 
I’ll follow up with more detail (this was a simplified explanation) and some posts on the rest of the sequencer as time goes on…
