# Tuplet Clock Divider on Teletype?

so the goal with this is to create a tuplet clock divider. 7 over 2, 5 over 3 and eventually more complex rhythms, 7 over three with a triplet on the third tuplet. a la. zappa, ferneyhough etc. but i am stuck. i can find the right numbers (i think as they are untested) but can’t figure out a way to turn these numbers into a trigger (TR.P). For example, A in the script below is 142 milliseconds. if i were able to set a trigger every 142 milliseconds against M at 500 this should translate to a 7/2 tuplet, i think… and in this example Y is 7/1 & B is 5/2 etc.

anyway, i’m stuck. any help or insight would be awesome.

M:

TR.P 1
M BPM 120
Y / M 7
X * M 2
A / X 7
B / X 5

1 Like

Switch M to the highest resolution tick involved. So,

``````M / * BPM 120 2 7
``````

Would get you 7/2 on 120. (edit: If 7/2 means “7 notes over 2 beats”)

If you want the polyrhythm, use temporal recursion with 2 scripts. Vis:

``````1: TR.P 1
DEL / * BPM 120 2 7: SCRIPT 1
2: TR.P 2
DEL / * BPM 120 2 5: SCRIPT 2
``````

Note that these will probably skew in time due to rounding errors stacking up. You might want to find a common multiple and sync things up at that point.

``````M: DEL.CLR; SCRIPT 1; SCRIPT 2
I: M * BPM 120 35
``````

Uh oh, `500 * 35 > 16384`. So uh this might not be possible at 120 BPM. 130 and up will work, though.

Also, because the rounding error is going to result in ticks that are slightly too fast, the sync action is going to produce 2 trigger pulses unless `TR.TIME` is sufficiently large to mask the second trigger.

6 Likes

this is great, thank you! lots to explore here.

1 Like

If/when you have an output expander, you can use some of the extended functionality to do this easily. Here is a sample setup script that outputs the aforementioned subdivisions (2,3,5,7) on the four trigger outputs of the expander:

``````TO.M.BPM 1 120
TO.TR.M.MUL 1 2
TO.TR.M.MUL 2 3
TO.TR.M.MUL 3 5
TO.TR.M.MUL 4 7
TO.M.ACT 1 1
``````

The `TO.M` commands act on all independent metronomes for the device. The `TO.TR.M` commands act on the individual metronomes (one for each TR output).

Inside, the metronomes are locked to the master clock and don’t drift when subdividing. Any changes to `DIV` are implemented on the next outer beat, which also helps keep things locked together.

Now, things don’t have to be synced together between the four outputs. Acting on the individual metronomes directly allow you to slip and slide all over the place doing some really intricate phasing stuff.

8 Likes

this is awesome! if i understand this correctly this script would be for tuplets over 1, meaning 16th notes or 7 over 1 etc. with that in mind could you divide M to get other tuplets? maybe something like:

Would this result in 7 triggers in the space of two “ticks” of M i.e. the base tempo? or better said 7 in the space of 2.

I think I understand your question; apologies if I get it wrong below, I’m a little jet-lagged today from a week of hellish travel.

The `DIV` operator works within `M`. To get things working over multiple `M` tics, you would need to play with the tempo.

This example should (not yet tested - see “jet lag” above) create a 120 BPM `M` on `TR 1` and divisions against that M on `TR 2-4`. It sets `TR 2-4` to a metronome speed of 1/2 of `1` and then sets the appropriate divisions. The global `ACT` starts them in sync - though you can also do that with `TO.M.SYNC d` if the metronomes are already tic-ing away.

``````TO.TR.M.BPM 1 120
L 2 4: TO.TR.M.BPM I 60
TO.TR.M.DIV 2 7
TO.TR.M.DIV 3 5
TO.TR.M.DIV 4 3
TO.M.ACT 1 1
``````
2 Likes

this makes perfect sense, thank you. so then if you wanted to have the base of the tuplet as 3 you would set the M of that channel to 40 for 120 BPM. So for example TR 1 would be quarter notes at 120 BPM and TR 2 would be 7/3 at 120 BPM:

TO.TR.M.BPM 1 120
TO.TR.M.BPM 2 40
TO.TR.M.DIV 2 7
TO.M.ACT 1 1

Jeez, I must have been working too long to notice: the maximum value of an integer on Teletype is 32767, not 16384.

So this will actually work from somewhere around 60 BPM and up.

1 Like

just trying this now… as silly as it may sound this functionality is something i have been wanting for years. i have always done these types of rhythms via a computer sequencing or way back, on an MMT-8, but to be able to do tuplets on the fly in a modular synth sequencing environment is really something I have been wanting to do forever. so, thank you, so cool!

3 Likes

1 Like

Great to hear! You also sent me into a reverie about my MMT8. I loved that thing…

1 Like

i still use mine granted i do not have the patience to hand type tuplets into it anymore but i still love my MMT-8!

1 Like

Sorry for reviving an old thread but this is also exactly what I’m trying to do, I’m considering getting a teletype to make a tuplet performance sequencer.

Reading the above, am I to understand that this will only work for tempi where M can be factored by the number of desired quarter notes of the tuplet? I’m still learning about the integer limitation.

For example, with a tempo of 133 BPM on TR 1, can I get a tuplet of 17:4 (seventeen steps in four quarter notes) on TR 2 and a tuplet of 7:5 (seven steps in five quarter notes) on TR 3?

The integer division just means that the divisions will not be perfect.

For example, 133 bpm is going to be 451ms quarter notes. If you want 17 divisions of 4 quarter notes then each division should be ~106.118ms but `/ * BPM 133 4 17` will return 106ms. This means each of the 17 beats will land a little earlier than it should (0.118ms earlier). So the last of the 17 beats will be 17 * 0.118ms = 2ms earlier than the ideal case.

Depending on your choice of BPM and divisions, this error will be larger or smaller, or zero in the case when the ms corresponding to the BPM has the number of divisions as a factor. In most cases, the error will be small enough not to notice.

Expanding on this further, and to address @nbougaieff 's specific example, if you wanted TR 1 to do quarter notes, TR 2 to do 17:4, and TR 3 to do 7:5 you could use this:

``````# I
# Set up metro and make sure trigger times are small enough
# Can do this by making TR.TIME smaller than half a beat
M BPM 133
TR.TIME 1 / M 2
TR.TIME 2 / * M 4 34
TR.TIME 3 / * M 5 14

# M
# Trigger TR 1 each quarter note and call scripts 2 and 3 to manage
# other divisions every 4th and 5th beat
TR.P 1
EV 4: \$2
EV 5: \$3

# 2
# This will be called every 4 quarter notes. Use a delay to trigger
# each of the 17 divisions
DEL.R 17 / * 4 M 17: TR.P 2

# 3
# This will be called every 5 quarter notes. Use a delay to trigger
# each of the 7 divisions
DEL.R 7 / * 5 M 7: TR.P 3
``````

Because the metro is restarting the calls to `DEL.R` each 4 and 5 beats, the small errors will not accumulate over time, so the worst the 17:4 rhythm will be out is ~2ms, which should be acceptable.

A potential issue with this sort of approach due to integer limitations is the maximum integer limit in Teletype of 32,768. If, during the calculation of the division time in milliseconds (i.e., the `/ * M 4 17`) the values get too large you can run in trouble. For example, if you tried to do 71:73 you would need to compute `/ * M 73 71` but if `M` is 451ms then `* M 73` is going to be 32,923ms which is larger than 32,768, so Teletype will wrap this around to a negative number and give very odd results.

6 Likes

Thanks that is really helpful! All clear except the very first part, why do you make TR.TIME smaller than half a beat?

Why don’t we have something like this:

``````M BPM 133
TR.TIME 1 / M 1
TR.TIME 2 / * M 4 17
TR.TIME 3 / * M 5 7
``````

The TR.TIME op sets the time that the gate is on when TR.P is called. If the time the gate is on is the same length as the division then the gate will effectively be on permanently, since there will be no time for the gate to switch off again.

Setting the TR.TIME to half the division length means that the gate will be on for the first half of the division time then off for the other half.

3 Likes

It looks like TO.TR.M.DIV does not exist, did you mean TO.TR.PULSE.DIV ?

As far as I can tell, DEL.R is highly inaccurate, very audible jitter at fast tempos (with a delay time time lower than 110 ms or so)

On a related note, been wrestling with getting a signal out of the TXo. Got the clocks ticking away at different speeds, the lights are ticking away, but no signal at all from the outputs. Created a separate thread on that — No output on a TXo

That’s a shame that DEL.R is unstable. I haven’t noticed that myself, but I also haven’t been trying to do super accurate timing.

I don’t have a TXo though. Maybe you meant to reply to a different message?

Yeah, indeed. I did many tests with DEL.R, stripping down a script to exactly the approach you suggested. Could clearly hear it and confirmed it by recording audio and comparing it to the DAW grid.

The TXo thing is another solution earlier in this thread — I just meant to generally share my experience with anybody else who comes across this topic!

1 Like

not just `DEL.R`, all `DEL` have +/- 10ms jitter