Teletype workflow, basics, and questions

features from experimental firmware stay undocumented until they are officially released. The Teletype feature requests and discussion thread is the place to go for bleeding edge features and information about them. However, you’ll often have to do some digging in the thread to gain a sense of what the features are and how to use them.


i confused these with their bitwise equivalents, which I’ve been running for the past few months, and which are currently being prepped for release.

R is root, S is scale, D is degree, and C is chord.

I have no clue about the JI implementation.

1 Like

Hello! Is there a canonical clock multiplier recipe?

I’m trying to put together a clock multiplier, and it’s not going great. I’d ideally like to have a clock coming in on one script input, and output a multiple on a trigger out, and avoid manipulating metro, if that’s possible.

What I’ve come up so far sorta works but is not great:

1: # this just stores time between triggers, avg/smoothed
# basically per studies 4

2: # Fires the trigger, and calls itself again after a delay
TR.P 4
PARAM.SCALE 1 8 # For 1x - 8x multiplier
DEL / X PARAM: $ 2

Things I don’t love about this:

  • it’s not synced with the “clock” coming in. It pulses at a rough multiple of the incoming clock, but not necessarily ‘on the beat’.
  • because we’re using integer math here, it doesn’t actually always line up correctly. The multiples tend to drift a bit, usually a bit faster than the incoming clock.
  • it takes up 2 scripts (ideally it would squeeze into one)

Are there better solutions for this? Apart from TELEXo, which I see has M per-trigger out and also multipliers for that metro, which I assume would line up better. But, I’m curious how to do this in ‘vanilla’ Teletype.

Dividers are dead-easy, but this seems a bit trickier.

Thanks for any help!

EDIT: this is working a lot better, but if there is a 1 script solution, I’d love to know. Thanks!

$ 2

TR.P 4
Y - Y 1
DEL / X PARAM: $ 2

How about one line?


That works great! Still needs the param scaling but there’s no need for it to be a true one-liner :wink: thank you!

1 Like

The Something Of Teletype thread should answer some of these questions and give some insight into design ethos and history.
I dont know enough to answer the others, but when you see the list of ops that existed on the original 1.0 teletype, you get a sense of the sorts of things teletype was originally designed to do, and it seems like it would have been a very different kind of module back then. All the amazing incredible things teletype is now, (and probably the things that make us wonder why there aren’t bipolar outs, or scrolling screens) have all been more recent additions to the core idea.

I am both intrigued as to what a full hardware refresh would look like for TT (there actually was a relatively recent hardware update that mostly addressed usb and i2c power issues) and am simultaneously also a quite scared of the possibility of it happening, for backwards compatibility and script sharing reasons. Based on what I know of teletypes design ethos, a new teletype would have to make sure that any scripts written on that new teletype would still be able to run properly on an old teletype.

Also, part of the design at the core of teletype is that it is basically a really really early computer.
Like, it’s called a teletype.
Baked into the name is this idea that newer technology is not always better, and something only really goes out of date when the designer decides to stop supporting it. Coding on a device that has a quite old fashioned interface, and a pretty limited set of functions (it receives voltages, and makes voltages. That’s pretty much it) doesn’t have to feel outdated. That’s teletype.

The idea of a hardware update for teletype feels kinda redundant. It’s not like a phone, on the bleeding edge of technology, every month being redesigned and packed with new features, it is basically a computer from the 70s, and has a timelessness to it that introducing an upgrade cycle too would break.
I can see myself still using a teletype to make music in 40 years time, even when technology is all VR and neural implants :stuck_out_tongue:

I think maybe what is more likely would be a completely new and different module, that used the same language as teletype, but had a completely different feature set. More of a companion to teletype than a replacement. Like how ansible was not a replacement for the trilogy modules, but did have some overlaps. Although it uses a different language and needs an external computer, that module is pretty much crow.

Sorry this post is really long, I have been thinking about this a lot and would love to hear people’s thoughts on it.


So I am getting a weird behavior with using LAST …


gives me a constantly rising number that wraps after 32000 (like if the counter is never resetting).
Adding $ 10 to script 1 fixes it and gives me a ~stable value. It seems it gives me the last value of script 10 …?

What am I missing?

That’s odd - I can’t replicate that problem. If I put that in script 1 and call that script a bunch of times (e.g. from the F1 key) then X gets updated with the time between keyboard presses as expected.

Edit: I’m on CB56E83

Which firmware? I seem to remember there was a problem with LAST, I can look it up tomorrow. If you post a complete scene here (copy/paste from USB save) I can check what results I get here…

Ah good to know. I think I found it:

Firmware says 58DCD46.

I’m wondering if there is a way to reset the count of “EVERY X” , like resetting a clock divider?
Surely i’m missing something, but i’m having hard times trying to let this op to stay in phase with the clock signal i use for TT.

You can use SYNC x to do this. SYNC -1 will set all the counters to be one behind their usual trigger so that next time they’re called they’ll all rerun true.

1 Like

oh thanks, it was easy, i just found it on the documentation. Actually i don’t get how to write within the script, i mean i have to write SYNC -1 for example in the I script to let all the counters in the scene to be in synch, or maybe in the script where i set EVERY X?

Sorry, i’m still getting familiar with a lot of simple OP in TT

Seems that this actually a bug in the official. Here’s a fresh build hex from github for you:

2021_06_08_teletype.hex (742.4 KB)


It depends on what you want it to do, I think. For example if you wanted to be able to assign a particular trigger input to work as a “reset” to sync up all your EVERYs across your scene, then you’d just put this line in the script that corresponded to your trigger in. Then when that input receives a trigger, all your other bits of code will resync up again.

Question for @scanner_darkly @tehn @desolationjones : how about we change the auto generated checksum-ish ID to either be replaced with or appended a compile date? Like in this case the ID is (to me) only useful for determining whether or not the fwin question is the same as another. A date would allow everybody to at a glance recognize ah it’s the latest official (another word that could be included in the official builds).

Am I making sense?


i would append a date, since commit number is helpful for devs. the official releases should just display the version number imo.

want to make a PR? )


Maybe later, my plate is full ATM :slight_smile:

Oh perfect, thanks so much!

thanks Simon, i’ll try to wrap my head around it.

At the moment i’m using a TT trigger out to reset Kria patterns using EVERY 32 or 64 to extract a trigger from a 16th clock signal from Crow/Norns and this clock tick happens actually on the 15th position of a virtual pattern, which it’s actually ok to use it like a reset trigger, but if i want to use EVERY x for other duties in the same patch/scene, for example to trigger a chord or a simple steady sequence within TT, it’s sounds out of ‘phase’ about a step.