Teletype: Alternative firmware?

I made a table tennis simulator within teletype. Can’t find the video of it though.

It used the turtle operator (@) to bounce the cursor around the tracker screen. It could have been extended to use the 4 triggers for P1(up, down) P2(up, down) to make an actual game out of it.

I once considered adding graphics operators to the teletype codebase to draw on a new screen using the graphics acceleration of the display.

What I’m saying is that you don’t have to modify the teletype codebase that far to make games.

Also, here are my demo videos of various stages of the oscilloscope development:


Now that I’m thinking about it, I guess there’s actually quite a bit a of low- and mid-level commonalities between TT and for example Orca, like text parsing and rendering, grid-like structures and CV processing. The turtle operator also definitely has some similarities with the way things move in Orca.

This text based sequencer I’m currently prototyping is actually even closer to the way TT works and would probably just require some changes to the data structures that hold the current state and the way the scripts get parsed/processed. It’s in some whays a bit similar to spacetime and Dunes, which I both just discovered today (and which once again made me think about getting a Norns sometime).


Just wanted to post and say I would support the development of a full on tracker interface. That was my main draw to the teletype initially. It would be much easier to resist the NerdSeq draw that way!


Just wanted to send some good vibes your way @lsky. Both orca and some sort of purpose built tracker sequencer sound really (as does your oscilloscope @sliderule). Good luck with your embedded firmware development journey, and I’m excited to try out whatever you eventually come up with.

If you need anything on the docs side of things, let me know. I’m open to help add a section for alternate firmwares or something like that.


A tracker style sequencer would probably require even less fundamental changes to the TT firmware, since it already has some of that functionality.

I’m not very experienced with trackers, but I’ve tried Renoise a couple times and I really like how easily it can be customized/extended via the integrated Lua scripting API.

For the TT, an additional tracker view which can be used to sequence/trigger scripts could be an interesting way to get the best of both worlds…

Thanks a lot for the encouragement! There’s still a lot to learn, but as soon as I come up with something, I’ll make sure to share it here!

By the way, I’ve discovered this community just recently, but I’m already amazed by the positive, open-minded and supportive atmosphere around here. It’s very motivating and inspiring!

1 Like

A tracker (which goes beyond TT patterns) with integrated scripting would be the dream for me.

I liked the NerdSeq but eventually I got tired of typing in all the values - even with the Patch and Table functionality.

So you mean it would be more comfortable to enter the patterns with a full keyboard than with the NerdSeq’s rather limited user interface?

Renoise has this concept of phrases, which are basically sub-patterns nested within a pattern. So a single note can trigger a whole sub-pattern (kind of like a very fancy arpeggiator). Triggering specific TT scripts for single tracker-notes could be an interesting variation on that idea…

If you have a grid, the grid control mode’s pattern screen editing features are great. I’ve used it before to change cursor positions and values during a live performance.

It would, but I was imagining an extension of the current TT functionality where we can use Scripts to populate the Patterns, set loop points, move the play head.

NerdSeq has a similar approach with Tables and Patches which can be called from a single pattern entry.

The more I think about it, the more I feel I really just need longer TT Patterns and more of them. TT is closer to my ideal Sequencer than it seemed NerdSeq was ever going to be. :thinking:

This got me thinking: I haven’t often felt like I needed more or longer patterns, but I have found myself wishing a pattern could contain more than one value per step – e.g. one value for note number plus an auxiliary value for volume, filter cutoff, time, or # of repeats, etc. Sometimes I’ve used the most significant digits in a pattern for one purpose (CV 1 N / P.HERE 100) and the others for something else (say CV 2 VV % P.HERE 100) but the tracker UI doesn’t make it easy to edit individual digits of a step value independently. I wonder if alternative methods of displaying & editing the same underlying pattern data would be worth exploring, or if that would complicate things unnecessarily.


Multiple values per steps are also something that could be done by having the pattern trigger whole scripts instead of single notes. However, this approach would still be limited by the maximum number of scripts.

I haven’t done any research about the firmware’s memory footprint yet, but it would be interesting to know, if there’s still some headroom for more/longer patterns/scripts/lines per script. The current limitations might have been deliberately chosen based on design decisions and the hardware specs (display size, number of jacks etc.), so maybe there’s still space left…

1 Like

After giving it more thought over the last couple of days, More Patterns would be preferable to Longer Patterns. Being able to use Patterns P0 to P15 would be fantastic!


Interesting idea! I’ve used a 4 digit binary number in one pattern to control 4 triggers (on a TXo) - but you’ve made me think about embedding more info into a single step.

Some past discussion of alternative data views on the tracker page here.

1 Like

Absolutely, especially since the patterns are basically just arrays that can be used for lots of different purposes besides classic sequencing/tracking.

And apart from possible memory or performance limitations something like this probably wouldn’t require very complex changes to the firmware.

1 Like

I would bet that something will have to give, memory-wise - but I also think there’s definitely a case for a firmware that trades scene capacity for pattern capacity. Once you’re going deep with patterns, you probably already know what you want your scene to do, and you don’t need a lot of scene options on the machine at one time. I could see switching back to the factory firmware for R&D, then using a pattern-centered firmware once it’s time to perform and compose.

1 Like

Just wondering if it would be possible to turn TT into a 4 track tracker. Basically considering the 4 patterns as one « pattern » and a way to switch patterns.
I suspect that memory could be the issue, but maybe using a USB key ?

1 Like

Depends a bit on what you want it to do, but you can already essentially do this with the current TT firmware. Each scene has its own pattern memory stored with it, so you could have the same tracker reading scripts on each scene but with different pattern data and then switch between them by switching scenes.

1 Like

Yeah but it’s quite limited on memory.

It would be cool if you could programmatically load in scenes from an attached USB…