Telex: Teletype expanders


I might have missed it, but is the quantizer scale generator code posted anywhere?

It looks like there is enough memory and flash available for hundreds of scales …


Haven’t quite figured it out yet. My earlier pricing for the hand-built run is posted somewhere above (TXo = $175; TXi = $140; iiBackpack = $16). I wouldn’t want it to be too much more - but as I was doing things at cost with no labor factored in, I would imagine that pricing would go up to accommodate this.

There has been only a mild demand for additional units since the completion of my first build. With about 200 Teletypes in the wild and another 100 coming (according to @tehn in this post), it might be a while before there are enough new interested parties in the mix to make even a small production run viable. We’ve already reached 40-50% of users (depending on how many are still in the retail chain).

I may not have. I’ll take a look at it in the next few days and kick it out there. It is a simple little python script that takes Scala files and outputs C++ code that can be pasted into the TELEX firmware. It was quick, dirty, and way ugly if I remember correctly. :wink:


Great, that may help some of us microtonal experimentalists. :slight_smile:

I wrote my own quicker, dirtier, and almost certainly way uglier conversion script in the meantime. :open_mouth: I’m getting the same answers for 12TET you did (to 8-9 decimal places), so that’s a good check for both of us. One thing I noticed is that the hints in your scales have some strange spacings. For example, 12TET goes like this: 13 (fist octave, makes sense), 12 (OK), 11(!), 12 (OK) … and 12 from then on out. Do the hints need to merely be close? From looking at the source, it appears the answer is “yes, close is fine”.

While I’m on the subject, it also appears that notes are weighted according to the size of the intervals. In other words, if we had a major triad (0,400,700,1200) the fifth would get nearly half of the notes if we threw random values at it. Or am I interpreting the algorithm incorrectly?

In my own quantizer designs, I convert the incoming CV to cents, divide that by the scale’s span (usually a 1200 cent octave, but non-octave spans are OK) to get an offset, then map the remainder to the number of notes in the scale to get a scale index. The result is equal weighting and consistent execution speed (= very fast on an AVR, the ADCs on those devices are the limiting factor). Both approaches have their musical applications, and I think the ability to select either is a cool upgrade.

Thanks again for all you do! I didn’t know we were in such a small club. :slight_smile:


today while ordering parts for the next batch i came upon a mistake-- the original batch of TT was for 200, and we did another 100 after that. so this new batch will put it at 400 total.


Just wanted to say: I recently got my teletype and I’d absolutely be up for a TXo and TXi if you happened to do another run.


I would absolutely buy another TXo, and possibly another TXi as well.


@jnoble - I posted my dumb little python script for making the TELEX scales here:

Be kind - it was done quickly. :slight_smile:

Might be a bug - but what I did was create hints for each volt-octave. This cut down on the time it would take to scan and find the closest note. I’m wondering if there is some precision issue causing the 13-12-11-12-12 thing you identified. Haven’t had a moment to look at it.

The algorithm is designed to find the nearest note in the scale - not necessarily to do probabilistic interval distributions. I figured the latter would be done in the TT patch.

I also wanted to be able to use the processors on the two modules (TXi and TXo) to handle the math around finding the proper pitches. The TXi quantizes to note numbers in a scale, the TT makes decisions on how to interpret those notes, and the TXo transforms those interpreted note numbers back to the proper scale.

@x2mirko & @emenel - good to know. :slight_smile:

The revised numbers from @tehn suggest that another run might be more feasible than I thought. I’ll keep crunching numbers to see what it would look like.


Add one more into consideration for the second run! I was in the right place at the right time and was able to grab a TXi from @trickyflemming almost as soon as he listed it, and I’d really love to add on a TXo. I’ve considered DIYing it, but I’m still a bit intimidated by those tiny SMD components :open_mouth:


Does anyone have issues with the trigger outs of their TXo modules and the external clock in of ansible or trilogy modules?

I don’t have an accurate scope, but it seems that the trigger outputs are slightly less than 5V (around 4.25V?). The triggers work with Teletype and my other modules fine, but I can’t use TXo triggers to externally clock ansible or my white whale. The weird thing is that I can send 3V gates (at 50% width) from Pamela’s New Workout and that works fine for clocking ansible and white whale… :thinking:

Is there something wrong with how I’m sending triggers from TXo (simple scripts with TO.TR.PULSE or TO.TR.M at default width settings), something wrong with my particular module, or something with how ansible and trilogy modules expect external clock signals?


I don’t even own a Teletype (yet!), and I’m pretty sure I’d be down to buy some expanders if you did another run. :slight_smile:


Hi @jflee! Sorry you are having difficulties.

I’ve had only one other report of the triggers on production units not working with a particular module - it was Buck Modular’s Drumfuck. I was able to verify this with my own DF as well. I was able to make it work by simply passing the trigger through a buffered multiple.

This was a little perplexing as I had tested the crap out of the TXo over the last year with the DF (I had one of Skyler’s early prototypes). I then went and re-tested a production TXo with the 25+ modules (list at bottom) that I used to verify my prototype trigger outputs and found only one other that wasn’t triggering - the Tsyklon Labs Chaos Divider. (This was also frustrating as I had helped Frank with the build doc and tested the prototypes extensively with it! :roll_eyes:)

Just prior to my big build, I reviewed the circuit with @Galapagoose to make sure that the TELEX wouldn’t be harmed by the RUN jack of early Just Friends modules that hadn’t been modified. We made a slight change to increase the resistance on the trigger outputs to make things super safe. If you are looking at the circuit, we upped R102, R103, R104, and R105 from 1k to 10k.

I know that this additional resistance dipped the voltage a little under 5V. This value still is way over the 3V recommended by the unofficial Doepfer specification. However, your voltage seems lower than I would have expected. The TXo in my portable rig runs at close to 4.585V for every trigger when on. Is there any chance that your case is experiencing power issues?

A theory would be that the change to 10k dipped the voltage enough that some modules that are based on 5V microprocessors with certain input circuitry don’t like the output triggers anymore. It is odd because I have a number of other 5V microprocessor modules that are happy as clams with the TXo. So, maybe not - especially considering some of the evidence for the next theory.

Another theory would be that there is something about the change in impedance that some modules don’t like. That may be why, in your situation, 3V gates still work but the higher value gates from the TXo do not. This may also be why that my experiments show that going through a buffered multiple solves the problem with the aforementioned DF and CD. :confused:

I wonder if swapping back in 1k resistors for R102-105 would solve your situation? Or, is it a power thing?

Anyone else have thoughts? It’s clearly not a widespread problem - but one that I’d love to fully understand.

FYI: these modules all tested out fine with triggers from a production TXo in my home rig: Teletype, Peaks (in Drum Mode), LDB1 (Little Drummer Boy), Braids, Rings, Grids, Turing Machine, Erica Synth Pico Drums, 4ms Dual Looping Delay, Make Noise Tempi, 4ms Pingable Envelope Generator, 4ms Shuffling Clock Multiplier, 4ms Rotating Clock Divider, Ornament + Crime, Bitbox, Bastl Grandpa, Bastl Tea Kick, Make Noise Erbe Verb, Make Noise MMG, Make Noise Optomix, Make Noise Function, Intellijel Quadra, and Neutron Sound Orgone Accumulator.


Thanks for the detailed explanation @bpcmusic! Now I have a better idea of what’s going on.

I have plenty of power left in my case, so I don’t think that’s an issue. The output on my TXo may very well be closer to 4.585V—I don’t have an detailed scope, so I’m just eyeballing it when I compare the trigger output voltage with another voltage source using the scope view on my ER-301.

After trying things out based on your reply I suspect your theory about the impedance change on the trigger outputs is the key. The problem only seems to occur with Ansible and White Whale’s clock inputs; the trigger inputs of all the other modules in my rig seem to have no problem with TXo trigger outs. When I set up a TXo cv output as an oscillator to send a 3V pulse signal to Ansible and White Whale’s clock inputs, that seemed to work too.

I don’t have a simple buffered mult :astonished: but when running TXo trigger outs through Kinks (positive rectifier), Cold Mac (OR or rectifier), or simply passing it through Shades, Ansible and White Whale’s external clock inputs start responding properly. So maybe Ansible and White Whale’s (and other trilogy modules?) clock inputs don’t like the TXo trigger impedance? I know it’s a very specific use case, but I was confused when TXo triggers were working fine with Teletype but not the other monome modules in my rig.

Now that I have a better understanding of what causes the problem and how to avoid it I think I’ll be OK, but maybe this might affect future builds? If there are any other recommendations, let me know—I’m really enjoying the extra functionality of the expanders :grinning:


Hi @Leverkusen. Finally have put together a proper response for your oscillator questions. Apologies it took me so long; I wanted to make sure that I put together a clear response and also validate that everything was working as expected.

For those that want some context, @Leverkusen was seeing some wobbly oscilloscope output when outputting high frequencies. Here is the original post:

Here was my initial response about the way oscillation is done on the TXo:

Frankly, your oscilloscope videos looked so weird to me that I started doubting myself and thinking that there may be some firmware issue causing what you were seeing. (I use digital oscilloscopes that look don’t look quite as lovely as your analog scope.) After isolating and validating the fixed-point oscillator code and spending some time really looking closely at the oscillator output across a number of assembled units, I can confirm that what you were seeing on the scope was totally expected.

You are seeing the effect of aliasing on the output of the oscillators. These are extra frequencies that are created by the DAC (digital to analog converter) interfering with the audio-range output. As the TXo was designed to be a CV/Trigger Trigger Beast, the CV outputs have simple 1-pole RC filters ( -6dB/octave slope at 7.368 kHz). This kept the component count down and helped the device to fit in the required 4HP size.

For CV, this arrangement is perfectly adequate. For LFO and low pitch oscillations, it is still more than adequate as the artifacts are very hard to perceive. But, using the oscillator functions, the closer you get to the Nyquist frequency (7,812 Hz based on the TXo’s 15,625 Hz sampling rate), the more artifacts you create. They can get quite severe, as your video illustrated.

Now, the waveforms that aren’t sine waves will always have aliasing on the TXo regardless. It will be baked into the output in the audible ranges of the signal. Dedicated digital oscillators (like Braids) use all sorts of techniques to keep these to a minimum - including massive oversampling and running at 96k+ sampling rates, which puts the artifacts way out of hearing range. The TXo doesn’t have the horsepower to do this, thus the aliasing present in the audio range for these waveforms.

Sine waves have no overtones to alias, so the output in the audio range (below 7.812 kHz) from the TXo should be pure. The situation you were seeing is due to the fact that the post-DAC 1-pole RC filter has a gentle -6dB/octave slope. This allows a lot of the aliasing artifacts from the DAC slip in at higher frequencies of oscillation. The good news here is that if you want the sine wave to be more pure, all you have to do is to remove those frequencies with an additional filter that has a nice steep slope.

I made a little video that shows this. It illustrates the TXo outputting sine waves at various frequencies and, once there is visible and audible aliasing, a filter is turned off and on. I kept things simple by using the EQ mode from the ER-301 with both the low and high bands tuned to 7.44kHz and 60dB of attenuation for each band dialed in. You will see that the artifacts are reduced significantly once the filter is activated.

Click the video below to view this filtering in action:

Hopefully this all makes sense. Again, sorry it took me so long to put a proper response together. I wanted to make sure that I was thorough in both my investigation and my explanation. Please don’t hesitate to ask any questions if the above wasn’t clear. I am far from an expert in this stuff and may have bungled details in my attempts. :slight_smile:

BTW: you earn more about RC filters here if you are curious:


I remember you mentioning band limiting of the oscillators as a future plan. Will that by any chance help with the aliasing?


Thank you for looking at it again and the detailed explanation, @bpcmusic!

Both of the expanders are great as they are and it’s good to know about the limitations of the experimental osc. modes. Makes it clearer what is possible, where the boundaries lie - and that nothing is faulty that could be fixed.

I really appreciate how you gave insight in the development process as well as your marvelous support while I built my expanders and then getting to learn to use them!



For the sine wave, all you need to do is apply some additional filtering if you want to reduce the aliasing. This is a hardware limitation. For the more complex waveforms, software tricks would need to be done.

I played around with a PolyBLEP implementation that would have helped the Saw and Square waves, but ultimately dumped it before it was complete due to the growth in complexity, processing requirements, and futility when considered in the context of the 1-pole RC output filters. Ultimately went down the fixed-point path for the oscillator in order to gain massive performance improvements to squeeze in more simultaneous capabilities.

Were the Teensy processor to have more power, I would consider a higher sampling rate and some oversampling in order to improve the quality of the oscillators. While brute force, this is the cleanest sure-fire method to make the oscillation more high class (along with a better output filter).

No worries! I’m impressed as hell by your bravery and ultimate success with the build!!! :slight_smile:


Chalk a few Telex up for me if we do another run!


I would be interested in 1 TXi and 2 TXo if there was another run.


I’d be up for one of each if there’s a new run.


I’ve seen that @scanner_darkly has four TXo’s and one TXi and so I’d like to ask you too, how would a second (?) TXi benefit your system and how many TXo’s are you working with?