Teletype: Alternative firmware?

Thanks! This looks like a perfect basis for some first experiments!

I think so too, and the already existing C port could be a good starting point. However, being quite new to the embedded development game, I’ll probably begin with something a bit more simple.

Im currently working out the concept for a little pattern-based sequencing language, that could be suited as a first project. But I guess I’ll build a simple CLI prototype (probably in Go) first to figure out the ergonomics before starting the real thing…

There is a C implementation of Orca which may come in useful. Looks like they’ve split the ‘core’ library out into something with very minimal C requirements.

And hello @sliderule, nice to see you around here again.


I’m interested, please let me know if you have any question!
I would love to see Orca on the Teletype.


while libavr32 does abstract the hardware layer, some of the function calls are still pretty hardware specific (like taking a hardware pin number as a parameter, for instance), and you still have to implement quite a bit of low level plumbing. i’ve been working on creating a higher level abstraction that takes care of that, and the main goal is pretty much to make developing new alt firmwares easier.

some of the features:

  • providing the ability to configure voices and use functions to create notes which will then be automatically translated into a proper hardware calls - like updating CV outputs, or sending appropriate i2c commands to just friends / telex / er-301

  • easier interfacing with grid/arc

  • easier way to set up timed events

  • taking care of parsing HID events and translating them into more meaningful events like keyboard press etc (other HID devices will also be supported - shnth already is, and hoping to add PS3 controller support at some point)

this should give you an idea of what you can do with it:

another benefit of using it - it also abstracts away the hardware differences between different modules, so you could write a firmware once and be able to build and run it on any of the monome modules. it already supports while whale, earthsea, meadowphysics and ansible. for teletype i have it working as well (just need to commit it to the repo, will try to do it this weekend), i just need to add screen functions.

i was also planning to add support for some common things, like preset management and USB stick support - still hoping to do this, just not enough time.

take a look, the repo is here: i need to add documentation, but hopefully should be pretty straight forward to start. polyearthsea firmware is using this already, so you could use it as an example of how to set it up, and i’ll be happy to help with any questions.

@sliderule - nice to see you again!


Not usually a fan of alt firmwares, but Orca would be a great project and I’d love to see it. It will also be interesting to see how Orca on Norns + Crow plays out.


one request, if i may - for the potential teletype ORCΛ port could it have its own name, or some variation? there is already orca the alt firmware for white whale (and potentially other monome modules down the road, including teletype), it’s easy to distinguish between that and ORCΛ the livecoding tool since they run on different platforms, but it’ll be really confusing to have 2 different alt firmwares with the same name.


VCRO? :upside_down_face: (and 20 chars)

1 Like

There’s an implementation of a shadow buffered display driver in telescope. It’s not well-documented, but it comports to the specification set out in the display’s documentation, which is required reading if you want to play with the graphics acceleration engine.

Many of the implemented API calls related to drawing modes have been written and tested to some extent, but do not feature in the implementation of telescope. I had fun playing around with the scrolling modes and the box drawing and it all worked.

The diff-based update engine in use in telescope is well-appropriate to a scope, with few pixels changing each update. Depending on your needs, you may wish to use other re-map modes for better performance in complex scenes.

There are some builds of it starting about here:

As you can see in that thread, the diff engine in the final build was 4x faster than the full-column write in the initial builds, but only for the scope. It will be slower for a full-screen redraw, which is capped at 141 Hz, IIRC.

@sam, @scanner_darkly :wave:


Thanks for all the valuable input, hints and code examples! Looks like there is still a lot to learn and discover before I can actually get started with something as complex as an Orca port. But I’m already digging into the code and documentation and I’ll keep you posted as soon as there’s some progress!

Sure, I’d be absolutely fine with that. There should be enough other marine mammals out there that have not lended their name to a Monome firmware yet :grinning:

Just one more (maybe a a bit naive) question: Is there any possibility to do serious damage to the TT module by uploading an altered firmware? I’ve heard several stories about people accidentaly “bricking” devices, so it would be good to know what the worst case scenario could be. So far my experience with embedded development is limited to some experiments with relatively cheap MCUs and development boards, and breaking a valuable module would be considerable worse than a fried Arduino…

I really don’t think so. Nothing you can’t fix by just flashing back to the release firmware. I’ve accidentally flashed Teletype firmware onto Ansible and vice-versa a number of times, and have run bad code that behaved weird or soft-locked a lot of times, always fine after a reset/reflash. Generally I think scary things you can do are pretty well protected on modern microcontrollers precisely because stuff like accidentally overrunning a buffer is super common. Also, most hardware accesses you would want to do are abstracted away inside libavr32, so you generally don’t need to directly do any register twiddling anyway.


Thanks, that’s good to know!

Latest addition to my alternative firmware wishlist: A Super Mario port where the TT is outputting gates/CV for the background music and triggers for sound effects. Not going to build that one anytime soon though… :sweat_smile:


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: