Teletype workflow, basics, and questions

To be fair, 99% of the time I’m in the same boat: I, J and K are just places to stash intermediate calculations. The only times I have really had to dive into them have been for writing sequencers with variable note length, or in polyphonic scenes for operations too complex to fit in a single script. In those cases, I is your friend.

1 Like

pretty sure it’s because I is part of the execution state and J and K are part of the scene state. as far as i can tell there is no particular reason not to have J and K in the execution state.

(mod note: moved from a standalone thread titled linear drumming)

hello everyone, i’m new to teletype and i would like to ask you for advice on a very simple thing:

i would like to use TT to arrange trigs in linear form so they never meet, if i use the command
IF 1: TR 2 0
output 2 is disabled but continues to emit a trig only more attenuated.

i tried to use the TR.TIME without solving, same with TR.TOG B

i would like to do a sort of chocking in which the presence of a trig on A mutates the trig emitted by B and create a logical chain for the trigs.

how could i do?

thanks in advance!

I’d keep a variable X that always stored which trig was on
Then when I set X I’d do:

X <my val>
L 1 4: TR I EQ X I

this will loop over all the trigs, and turn off all the non-X ones, and turn on the X one


There are a few ways to accomplish choke groups for the triggers. I like @21echoes approach! You could also use the STATE OP to check whether another input is high. This might work well if you are processing external gates instead of generating a sequence in TT.

Example scene: takes gates into inputs 1-4, outputs matching triggers 1-4 but only if no other inputs are high.
Script 1-4:

J 0
L 1 4: J ? STATE I 1 J
TR.P $

@3-foot-1 wow thanks for doing that deep dive! Very interesting and informative.

@scanner_darkly is there any documentation on the execution state vs. scene state or should I just start digging into the Teletype source code?

The only thing that I can think of where having J or K in the scene state would be really useful is to maintain a per-script counter or previous value. Of course, re-setting such a counter would be tricky.

The feature where DEL can interact with the “current” value of those variables also seems cool, but I don’t think I’ve ever leveraged it.

If we were contemplating changes to the behavior of the variables at some point, I would say that making them behave the same way in S as they do elsewhere would be the top of my personal wishlist. Not that I know what version of “the same” would be the most correct or useful! But at the least I would make I copy its value from the script that puts the command on the stack.

Hello everyone and thanks for the help.

I’m trying to mess around with STATE OPs to check when an input is high or low and trying to organize the events with control flow commands.

I can see the values ​​0 and 1 on the variables X and Y if set in the M script:


but the speed at which the inputs respond is not the same as the gates I’m sending, so if I set a command like:


IF LT Y 1: TR.P 1

I manage to separate the gates and make sure they don’t overlap, but I lose almost all the ratchet of the original signal.

I’m filling the inputs with euclidean patterns generated by Acid Rain Constellation, maybe TT can’t read those gates correctly?

Sure I’m doing something wrong but I don’t understand what, I’ve had TT for less than a week so it’s all very obscure for me, I would be grateful if you could help me better understand where I’m doing wrong.

Thanks in advance!


L 1 4: TR I EQ X I

I can’t figure out what the variable I means here, I guess the variable X should be set as 0 or 1?


Thanks for the tip on the STATE OP! Again I can’t understand the I value, I’m feeding inputs with external gates and would just like to don’t have the snare on top of a kick and maybe a percussion and hi-hat logically interlocked.

X should be set to the trigger that you want to sound – a number 1, 2, 3, or 4

inside a loop (L 1 4:), I represents the current index of the loop. so it’s equivalent to the following:

TR 1 EQ X 1
TR 2 EQ X 2
TR 3 EQ X 3
TR 4 EQ X 4
1 Like

I there,
what is the best way to “pass” a gate signal that’s triggering a script to a TR output ? I simply want to control the length of notes with the input gate signal.
I know I could simply multiply the CV with a multiple or a stackable cable, but I’d like to not repatch my system between TT scenes and keep a minimal number of cables.
Best way I found is to set a fast metronome with for instance


But it’s not ideal in terms of timing, and I feel like I’m missing something obvious.

If you use SCRIPT.POL X 3 then script X will be triggered on both rising edge and falling edge. Try combining with STATE?


Amazing, thanks !
with SCRIPT.POL X 3in the init script, TR 1 STATE 1 in script 1 works perfectly.

A question regarding Grid Control mode: When Grid Control mode is engaged on e.g. a 128 grid, I understand that the grid control appears in the right half of the grid.

Assuming I have programmed some grid elements that appear only in the left half of the grid, will these still be operational when I engage Grid control mode? Thank much in advance for your help!

I’m trying to determine if what I’m seeing is correct behaviour and I’m misunderstanding something, or if I’ve found a bug.

N.B 0 R101011010101 set my scale to C major
JF.VOX 1 -1092 4000 plays a E
JF.VOX 1 QT.B -1092 4000 plays an F

Why does it quantise an E to an F here in C major? I suspect it’s something to do with the way minus V/OCT is treated.

The algorithm appears to quantise minus V/OCT as if it was positive voltage. For example.

JF.VOX 1 546 4000 plays a E
JF.VOX 1 -546 4000 plays a G#
JF.VOX 1 QT.B 546 4000 plays a E
JF.VOX 1 QT.B -546 4000 still plays a G#

@desolationjones looking at the commit history I guess you may have an idea of what’s happening here.

Known bug; will be fixed in next firmware release! If it’s critical I can send you a fixed beta hex.


Cool! I’m good pulling it into my custom branch - thanks!

Confirmed - works perfectly for my (very niche) usecase.


indeed, that was one of the reasons for placing the grid control UI it on the right when using grid 128 - the left quadrant will continue working normally, so you could combine your own UI and the grid control UI.


Wow, just discovering the note scale Operators…This is super exciting.
Does it allow to embed a custom note scale in your script, automatically generating a table of corresponding values, and access them with QT.B ?
What is the difference between N.B and N.BX ?

What’s this syntax ? Is it a way to write numbers in binary ?

Sorry for the stupid questions. Couldn’t find the docs…

(I’m not an expert, but I’ll give it a go). N.B sets the ‘main’ scale. N.BX I believe let’s you set one of 16 scales using an index (allowing more than one in use at a time). The first param is the 0-indexed root note (0 being C in this example).

The binary notation is simpler than it might seem. 1s represents a key that you want to include in the scale. Each key from C - B is represented. So R101011010101 simply means C is included (1), C# isn’t (0), D is (1), etc.

D major would be N.B 2 R101011010101.

This is briefly explained in the maths section of the manual.


Awesome, thank you !
Curious about the ‘R’ meaning.
Is N.B fast enough to be set dynamically in a script or is it better to first initialize a few scales and access them with N.BX ?

EDIT : Tested, it’s super nice, BUT, I’ve run into the bug mentioned above in the first script I wrote for this.
Negative voltages produce wrong values.
@desolationjones : I’d love to try working beta, if possible.