Telex: Teletype expanders


Telexi has no outputs; those are CV inputs


My apologies, I meant input port (not outputs)


Any further firmware updates in the pipeline at the moment? Otherwise time for me to update to v.021 beta (I’m way back on v.016 at the moment).


I read the FM, and was also quite confused about this.
So, am just saying: it’s not just you. It’s a little under-explained… :wink:


Sorry if it is confusing. I tried to keep it as modular and flexible as possible. And while there are multiple mentions in the manual and examples in the new Teletype manual as well, it really takes until you “get it” for things to make sense. I’ve half-built some studies for the TXo that I really want to finish and share sometime. I think that will help a lot.



picked up a second-hand TxO from Control, installed the latest firmware, both on the txo teensy and on teletype, but can’t seem to get things working.

any telexo-based command i type anywhere in teletype causes teletype to freeze up permanently until powered down, and I get no visual response from the telexo. any ideas?


It could be that he i2c cable is orientated wrong on one end. I had the exact same problem when installing my TXo recently.


are you able to test with something else connected to teletype via i2c?


turns out I was connecting the i2c cable to the wrong header, specifically the one with 6 pins, which I assumed was the correct one to plug it since the i2c cable has 6 pins. connected the cable to one of the 3pin headers and working like a charm!

couldn’t find anything in docs anywhere about this, so perhaps it should be added for 100% clarity’s sake :nerd_face:


Sounds like you didn’t get one of the manuals with the module from Control. You can find the latest full manual here:

Lots of helpful stuff in there.

@rikrak and @scanner_darkly - thanks for stepping in to help!! :slight_smile:

@n-So - hope you enjoy your TXo. For others who are interested, the production run is getting ever closer. Unit QA, Teensy prep, and boxing left to go… :slight_smile:


Also … don’t forget the TELEX section of the full Teletype manual. Command reference with some examples and helpful hints there too:




Is there any timeline for the telexi-modules’ restock? Thanks!


Soon. Soon. Soon.

Doing QA and prepping boxes. Making i2c cables. Stuffing screws into little baggies. Also, waiting on a final Teensy order.

I’ll announce the date and time things will go on sale here a few days before. You can also sign up for automatic notifications at my store.

Really sorry to take so long. This build has been gargantuan beyond my expectations. Believe me - no one wants it done more than me. :slight_smile: :slight_smile: :slight_smile:


Absolutely no worries - I haven’t even kept track until now, so sounds great to me :slight_smile:


I’ve really been enjoying the TXo. Still learning the many things it adds to Teletype. Here’s a little generative two voice jam with the TXo providing clocks via its independent metronomes, envelopes, and oscillators. Oscillator wave forms are randomized per voice and note. Great fun!


I have a question about i2c and the time it takes to communicate. I had some issues with the communication between Teletype and Just Friends, where commands were sometimes being dropped if I rapidly sent commands (e.g. in a loop).

I currently have two TXos and no such issues. However, I’m thinking about picking up at least two more with the next run and I’m wondering if there could be similar issues as I had with Just Friends and, more generally, what ballpark the latency would be in when looping over all outputs of 4 or 5 TXos and setting them to new values. Does anyone know an estimate of how long it takes for teletype to send an i2c command to a TXo?

My main application is a rather complex step sequencer (with lots of outputs) and so tight timing is sort of important. I have no issues so far with two TXos, just want to make sure that there’s nothing to worry about with twice as many :slight_smile:


it should be very small. i have 4 txos so i’ll measure it and report back (traveling now so won’t be able to get to it until monday though)


Thanks and no worries, it’s not urgent at all.


I’m all torn up in production mode, so I don’t have any stats handy either. I remember there being a discussion about this in the past on the forum, but I have been unable to search and find the relevant posts.

My experience is that communication is quite swift. I only was able to perceive a flam when I had 8 TXo connected and was sending a number of commands to each one at the same moment. I was torturing it on purpose. :slight_smile:

Something like:

L 1 32: TO.TR.P I
L 1 32: TO.OSC.N I P RAND 32
L 1 32: TO.ENV.ATT I RAND 30
L 1 32: TO.ENV.DEC I RAND 250
L 1 32: TO.ENV.ACT I

In the example, there are a lot of commands between the PULSE and the ENV.ACT commands, which could put a delay between them. It all comes down to how many sensitive commands you are trying to send at any given moment.

I’ve been able to solidify the timing by using the DEL operator to better fix the timing of the things that produce the sounds and then do the setup in the intervening window. For example:

L 1 32: TO.TR.P I
L 1 32: TO.ENV.ACT I

L 1 32: TO.ENV.ATT I RAND 30
L 1 32: TO.ENV.DEC I RAND 250
L 1 32: TO.OSC.N I P RAND 32

This gives the setup the time to take the time it takes and the “sound activating” commands are sent as closely in succession as possible. (The length of the delay depends on what you have going on. I just picked 15ms for this example.) Think of it as the breath that wind players take before the note sounds.


tested with 4 txos. with nothing else running doing L 1 16: TO.TR.P I the last (16th) trigger output was 2.5ms behind the 1st. in similar test with CVs it was 3.5ms.

didn’t run the test multiple times, so this is just from a single measurement, but should give an idea.