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.
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.
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:
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.
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.
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:
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!
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.
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.
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
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!
