Monome Teletype and Walk

Hum i’m also asking myself if there is any way to use Teletype as a clock multiplier/divider or something like a trigger repeater/delay. I can’t find my way out to “duplicate” the incoming trig.

What specifically are you trying to accomplish?

I want an incoming trigger to be repeated to make trills for instance, or maybe unsteady rhythms, and make it happen with a certain amount of probability ( i got this part covered ).

So. I got this going with the Triumvirat. One really big problem was the really very much too short cable for connecting the modules, as it allows only one way to put the modules in the case (the Trio left of the TT). But I found a good solution, and will maybe make my own cable.

I just tinkered with the preset patches espacilly those controlling the Trio, and I almost forgot to go to sleep. So much huge potential. Will tinker more. The perception of my whole modular just shifted immensly.


There are number of things you can try.
Easy one would be to first play with delays:

DEL a : execute

which you can place for example on script 1, so every time you send a trigger to that input, it will execute that script:

DEL 250 : TR.PULSE 2
DEL 500 : TR.PULSE 3


so in the above case your single trigger will produce 3 triggers coming out of three TT outputs.
but you can scatter them coming out of the same output as well, which will produce a mini sequence of triggers, each 1/4sec apart:

DEL 250 : TR.PULSE 1
DEL 500 : TR.PULSE 1

Add RAND instead of specific time values, and you will have a more unpredictable timings:


Playing with these can go a long way.
ALSO, you can patch an output of your TT trigger to another TT input, where you can have additional scripts, so say your TR.PULSE 2 output is actually patched to input 2 on TT, where you have another script that produces additional pulses, with different values, etc.


Then there is the internal TT metronome M.
Possibilities of using this for your objective are endless, but just to get you started:

put this in script 1:

M RRAND 100 1000

put this in script M:


What will happen is that now you will have a very chaotic output of triggers coming out of output 1. The scripts first sets a random time interval for the metronome, each time you send a trigger to input 1. It will be somewhere between 100milliseconds and 1 sec. Then it turns the metronome on or off, depending on whether TOSS will produce 1 or a 0, so the metronome will effectively be turned on and off randomly. And when it is on, it will spit out sequence of pulses, at that random time value, until next trigger to input one randomizes the time interval and/or turns it off again.

This will be crazy and random, but you can be very specific too. For example.

put this in script 1:

M 500
DEL 2000 : M.ACT 0

put this in script M:


So, each time you send a trigger to input 1, it will turn the metronome on, which will spit out a sequence of pulses for 2 sec. at 120BPM (every half a second).

Am not sure if this is what you are looking for, but these are some examples where you can start playing with structures and patterns.
Hopefully this helps.


This is a great run down!

If you really want to do clock multiplication, you can use the TIME function to count the number of time between pulses, then divide this time by a constant. You can use the RSH rightshift function for easy divisions of 2^n (for musical intervals):

M RSH TIME 1 // divides the time since last input in 2, then sets the metro time to this value
TIME 0 // restart the timer count for the next interval

TR.PULSE A // sends pulses at twice the input rate

The above creates a simple clock multiplier at x2 rate. You could use this same structure with different RSH values, or use more abstract math like a direct MUL or DIV for non powers of two. You could even add offsets with ADD or randomly select a different multiplier with eg: MUL TIME RRAND 1 4 which would choose between multiples of 1 through 4.

Note with the above that the metronome is free running and not explicitly linked with the incoming trigger. If you want a new input to reset the counter you could slightly expand it by resetting the METRO time and generating a trigger immediately:

TR.PULSE A // create a pulse immediately on input
M.RESET // reset the Metronome counter to sync to the incoming trigger



thread is getting deep
(in the best way possible)

Q is a queue of values. A short list of the most recently received numbers. It’s a short line of memory for analyzing a short stream of data, or even just delaying data a given number of steps.

You set how long the register is (how many stages of memory) with Q.N

If you send Q a value eg: Q RAND 3 it will add that to the end of the queue and move everything currently in the queue forward by one step.

If you read Q eg: CV 1 Q you will get the value at the front of the queue. This value has been effectively delayed (or ‘shifted’) by however many steps you configured in Q.N.

You can use this in a classic way by setting Q.N to 3 or 4, then sending your CV 1 output values into the Q as well as directly to an output. Then also readout the Q to the second CV output. This will create an ASR (analog shift register) where the values are delayed at a control rate, rather than a time-based rate like an audio delay.

X N RAND 12 // pick a random semitone within the first octave
CV 1 X // send the note to CV 1
Q X // add the value to the queue
CV 2 Q // read the value at the front of the queue and send to CV 2

Q.N 3 // initialize the queue with a length of 3

Of course you can take this much further and use it to do many other things. The Q.AVG is a powerful way to take a moving average of the most recently received values. You could for example have a totally random output on CV 1, but then have an averaged (smoothed) output on CV 2, with the amount of smoothing controlled by Q.N:

X V RAND 10 // set X to a random even volt value 0 - 10V
CV 1 X // output X directly to CV1
Q X // add X to the queue
CV 2 Q.AVG // send the average of the queue to CV 2

You can then change Q.N via live mode, or some other script to set different amounts of smoothing.


@Galapagoose Just last night I was trying to work out how to recognize an incoming tempo to set the M in relation to it.
I ended up with a similar approach (picture below) of using TIME, and resetting it to 0 within single script. I wanted to set M to a time signature slightly slower than the incoming triggers, so I am adding the 3ms to the X variable, which is being calculated on every trigger to the TIME value. This way, if the incoming trigges slow down or accelerate, my M will always re-adjust.

Yeah that’s nice. I was thinking of walking through using Q.AVG to smooth out any TIME detection drift, but feel like the TIME is actually pretty solid. Nevertheless, if you want to add a little backup for a slightly drifty clock, it would be pretty easy. Something like this:


While the above won’t be synchronized with the incoming trigger pulse, it should track the overall tempo very accurately, even if there is dramatic changes in speed.

1 Like

@laborcamp @Galapagoose

Ok thank you very much for all that intel :neutral_face: It will takes me forever to master all that stuff ( in a good way ). This module is far deeper than i first thought so i can’t be happier of my investment. Nice move !!

@tehn Little suggestion: why not adding all those examples to the manual ?

Yes! Perfect explanation.

Care to elaborate similarly on Stacks? :flushed:

Thanks so much!

1 Like

Oh yes - that’s mostly my job! The good thing is it’s pretty easy to transplant these examples into some documentation. This kind of in-depth exploration would probably be great content for Tutorials rather than the main manual (it’s already pretty long!).

woh, i just made a homemade Dual Temporal Shifter, ala Synth Tech. haha.


I’m not the best person to explain this as the whole ‘Push’ and ‘Pop’ methodology is something I’m not really used to. However, it is a very useful method for implementing quantization of events.

The essential idea is that you choose one (fast) trigger, or the internal METRO as the quantize clock which simply contains:

S.ALL // executes all commands currently in the stack

Now all you need to do is setup your other scripts as per normal, except add the stack PRE. This will add the commands into the stack and they’ll wait until the next quantize tick before being fired off. This would particularly useful if you have two separate clocks that don’t have a strictly defined relationship.

S : CV 1 V RAND 3

These two commands will thus wait until the METRO event as above.

1 Like

So what is II ES.CLOCK supposed to do exactly?

cool. i’ll give that a shot.

First you need to enter enter TT clock mode for ES:

You could put that line in the I script so it is set when you load the scene. Or you can just tab into Live Mode and type it directly.

After this you just send ES_CLOCK a number (the actual number just needs to be non-zero but doesn’t mean anything else). This event will cause ES to advance to the next event of the current pattern. It should be noted that presses & releases are separate events which preserves things like legato playing. Any recall of shapes is recalled as an event as well.

To think of it another way, it’s an event-based clock, rather than the time-based clock that ES uses internally. Thus you can change tempo dynamically, but also it requires the rhythm to set by the incoming clock.

1 Like

It worked, and it’s the first time my earthsea pattern plays in sync with the rest of the case!

1 Like

Hm, I’m really trying to wrap my head around how this should work, but what’s the deal with the number. How can I clock ES with an external clock?