Telex: Teletype expanders


The IDE is pretty crap when it comes to dependencies. I have a feeling that there is not a lot of flexibility in this regard, but I haven’t asked if it is indeed possible (or done any experiments).

Good call. :slight_smile:

I was surprised that our two systems differed by 20ms.



Talking about your Script above with the ENV.EOR and ENV.EOC…If I understand this Scene correctly…

Each single M Script blasts Script 8 4 times?

Then, as 8 gets triggered each time, B is read as 1, then line two it becomes 2, then on the second Script 8 read it is read as 3 and 4, 3rd Script 8, it is now 5 and 6, etc…

So those looped reads of Script 8 happen REALLY fast, eh?

1 Like


Is A needed? Can you use I instead?



Yes. This causes it to read all 8 of the TXi inputs that are a part of the script. They alternate affecting attack then release for each of the four envelope generators.

With the work that everyone has done on the i2c stability and performance, the answer is yes. You can pound the snot out of it.

A read is more complex than a write (slower too) - which is why it is the first to show instability when there are too many devices connected without a bus board. So the rate that you execute them is worth some consideration.

Best practice is to store the value in a variable if you are going to use it multiple times. Also, you don’t need to run the M super fast for things to feel responsive from a control perspective. I’ve noticed that when controlling CV from the PRM inputs that a tiny bit of SLEW can go a long way to butter up the output. :slight_smile:

Yup. Good catch; use of A was redundant given the global nature of I. :slight_smile:


L 1 4: TO.CV I V 5
L 1 4: TO.ENV.ACT I 1
L 1 4: TO.ENV.LOOP I 0


B 1
L 1 4: SCRIPT 8





Thanks for the info, guys! (I will ponder the ‘A’ comment whilst I nurse this Manhattan🥃)

1 Like



I’m hoping that with my new TXi I can ‘play’ some sequences into the teletype from my metropolis for recording. I will use the regular IN on the teletype to store the CV to a pattern, but I’m trying to figure out the best way to record gate time. I think one way is to mult the metropolis gate out to one of trigger inputs on the teletype and and one of the TXi inputs. Then when I receive the gate and execute the script, can I do something like:

T 0
L 0 X : IF TI.IN 1 : X add X 1
PN 2 (step count) T

I don’t think nested PREs are available. There isn’t a return call so it doesn’t make sense to call a script within a loop. Any ideas?


Teletype: measuring gate length

What if you mult’d and inverted the gate, so you have one script triggered when the gate begins, and another when the gate ends? Then just calculate how much time has passed since then



I could do that, but that would require another module (not that I mind).

EDIT: I would prefer just an unpatched solution so that when I stumble upon something I like I can just call up the appropriate teletype scene…



not very elegant, but you could use a fast metro and poll a script input STATE for high/low. then use the TIME param to keep a count. high state resets T to 0 and starts counting. low state sends current T value to a pattern index and resets T to zero.
this is untested brainstorming, can’t guarantee it’ll work…

also, i’ve noticed when recording sequences (from earthsea) into teletype i sometimes have to delay my read of IN by 20ms or so as the CV output will update slightly after the gate pulse. might be different with metropolis.



Ok. I will give that a shot. So maybe use one of the triggers to set m.act 1, multed with TI.IN 1, and then when the metro script detects it going to zero it sets M.ACT 0.




Would love to see where you end up; the patch sounds quite interesting!



forked this pursuit:

@bpcmusic - a TXi specific gate measurement function would be pretty awesome…



Would you like instantaneous, average, or both?

1 Like


There is a command line build/flash tool that is supplied with the Arduino IDE. It’s a pain to set up in a Makefile especially if you’re trying to be platform independent, but it can be done. Shout out if you ever what some help getting it to run.

1 Like


Hi Everyone,

I have build both telex modules and they are great to work with. Lots of fun to have with all the possibilities they offer in conjunction with teletype. I am very thankful to @bpcmusic for designing and supporting these.

Just one thing makes me wonder if I had mad a mistake during building (was my first serious SMD built) or if it’s just as they work.

The TXo oscillator output does sound and look a bit strange. There seems to be another oscillation behind it - like this:

Anyone experiencing somethin similar or has an idea what’s going on there?





I’ve been scratching my head as to what you are experiencing. I’ll first explain a bit about how the “experimental” oscillators work and then share some more specific thoughts and comments about getting to the bottom of your experience with the feature.

How the Oscillators Work

The TXo sampling rate is at 15,625 Hz across its four oscillators. This means that the top frequency that each can produce is 7,812 Hz.

The oscillators themselves do no oversample. This means that sine waves will produce pure tones up to the top reproducible frequency (the nyquist rate). Other waveforms (triangle, saw, and square) will alias. This means that they will create ghost overtones or digital distortion that is present in the output.

As you may have noted above, sine waves should not alias when performing a simple oscillation. Rapid changes to their frequency or CV min/max could potentially introduce aliasing into the signal. A tiny amount of oscillator frequency slew can help abate this a bit, btw, if you are going to be programmatically changing the frequency rapidly.

The oscillators in the TXo run from what are called lookup tables. The tables in the TXo are currently made up of 512 values - although that size is planned to grow in a future firmware update. The size of the lookup table is directly related to the quality of the signal (bigger being better).

The TXo implements a technique called linear interpolation to improve the quality of the oscillator regardless of table size. It estimates values in-between the points outlined in the table. This technique is active when oscillators are used without additional features being active.

Once you turn on any extended features for that oscillator channel (envelopes, frequency slew, rectification, …), interpolation is disabled in order to provide the appropriate processor resources to the voice. This means that you will see some additional distortion if using an oscillator in an extended mode, even with the sine oscillator.

We’ve got more room for a larger lookup table after some recent memory optimization, which will improve quality when interpolation is disabled. A future firmware update will most likely increase their size.

Your Experience with Oscillators

I’m trying to figure out what is going on with your demonstration. Could tell us a little bit more about your oscilliscope and method for altering the frequency. What does your Teletype script look like? What does your oscilliscope look like showing the output of an analog oscillator doing similar things (with similar waveforms)?

Congrats again on the build!! Very glad that you got them up and running. :slight_smile: :slight_smile:



Thank you - it was a joyful and educational experience! :slight_smile:

Also thanks a lot for giving an insight in how TXo works! I understand that the oscillators are ‚experimental’ and I would not expect this function to work the same way as an fully featured analogue ocillator would work. It is just that I wondered if there is something else going on behind the aliasing / digital distortion and thought we might figure out what it is since it would be a shame if it just was something due to an possible error in building the module that could be easily fixed.

Regarding my demonstration: I worked with an analogue oscilloscope (Grundig GO 15Z) that shows waveforms of other (analogue) oscillators or envelopes in my system as they would be expected.

The teletype script from the demonstration just mirrored a TXi knob to oscillator frequency for the demonstration - when I do change the frequency with simple commands in teletype live mode all waveforms look the same as they did in the video.

Also I can not make out much of a difference by sight when I enable slew or rectification for any oscillator.

Let me know when there is anything else I could check…





It’s the firmware, I think. Something got buggered and I missed it.


Give me a few days to get to the bottom of this. I’m traveling for the next few days and might not get good concentrated time to do tests.



Thank you for the feedback - great to know that it’s not a hardware issue and that it is fixable.

No need to stress yourself - travelling needs recovery times.


1 Like


50ms startup delay added:

(aiming for 2.0rc2 to come out today, with 2.0 final to be released at the weekend)