(Teletype) Pre-2.1 Operators and Features


I see some implications here I find worth to consider.

First you might need a place (I; TL) where you can set the variables for one (each?) R. The script it self might not be a proper place to do it as it would eat up space there plus something like R.COUNT 1 -8 should not work from within script 1 itself since it is self referring.

Also you need a place (i.e. a second script) to set an R script active, especially when you want to have it reacting on external trigger inputs, which would be nice combined with the count/countdown feature.

So this might lead to bumping into the constraints of teletype much easier than now, which might lead to the expressed need again for more scripts, longer lines, longer scripts or shorter Aliases as the use of multiple TX modules already does.

I think a clear conceptional framework is needed to decide if and how these new features should be implemented. Also to keep in mind what is possible - there are annoying glitches on the screen. They do not seem to affect functionality atm but I don’t feel confident with implementing bigger features as AT and TL as long the actual firmware seems to work so hard that I can not read the screen anymore.


augh, fixed typo all the way through

repeat is autotrig. i think it’s useful to decouple “trigger” with this command as “trigger” is output-oriented, whereas a more accurate description would be auto-script. but “repeat” is much more elegant. i don’t see the semantic issue with the word-- i think your assessment holds for “echo” however.

i think F is a solid choice. sam’s suggestion for making a mod to edit F lines is great, encapsulating his previously-named-F feature into one single feature, the previous-named-TL.

i’ve been considering these features for almost two years now, so i plan to implement them. yes, the hardware can get pushed to its limits. but this is the nature of an open-ended system-- you’re probably not going to be able to use 100% of every feature all of the time-- just like the computer you’re using now can’t do more than it’s capacity for computation. but @sam and @scanner_darkly put in a ton of good work to have sensible fallbacks on when the processor is overtaxed, an no hard crashes. these features will be very very powerful for new ideas, and making them not available just because you can’t run all 8 metronomes and have all 8 input triggers blasting at near-audio-rate and have everything go smoothly-- this isn’t a good reason not to implement the feature. in a more subtle use-case these features should work wonderfully and there shouldn’t be screen glitching or timing loss.


not a new OP but how about fixing JI which I believe is still not working properly? @Galapagoose mentioned some time ago in another thread he was working on it.


Brian, I don’t want to discourage anyone to implement those new features - I think they are great and I am looking forward to work with them!

Regarding the polemic part about blasting things at audiorate and what a computer can do - here is a short video of teletype studies 3. I do not find it overly complex with one M and three input trigggers running at quite a bit below audio rate. If you watch closely you see that in script 1 every now and then a whole line is missing on the screen and only reappears by moving the cursor, the tracker mode gets disturbed by lines from edit mode and therefore a line from tracker mode appears in live mode. Also, but not in this video, I experience partly shifted lines in edit mode that are just unreadable.

Especially unreadable or misising lines are very annoying and distracting cause I can not judge at a glance if what I see on the screen is what is happening at all and I would really appreciate if these bugs get fixed before you implement more features that bring the firmware even more to a limit. For me to accept that the screen is not reflecting the actual code is not dealing with constraints but just bad und unfunctional design.


thank you for pointing out this bug-- i wasn’t aware of the problem during normal use. it should surely be a priority before adding more features.


Great - Thanks! And let me reassure you that I have absolutely no interest to push the things in the extreme just for the sake of and I do not see much musical use in letting everything flicker at audiorate either…


The 2.0 release notes mentions “visual glitches” as a known issue :

“The cause of these is well understood, and they are essentially harmless. Changing modes with the key will force the screen to redraw. A fix should hopefully be coming in version 2.1.”

Is it these glitches that are displayed in the video above, and is a fix still scheduled for 2.1 - @sam @sliderule ?


I wasn’t aware of this issue. If someone opens an issue on GitHub, I’ll try to track it down for 2.1


Brian opened this issue:

I know exactly why it happens… but it was too late in the 2.0 process to try fixing it. The short version is:

  • CV outs are updated using a timer…
  • The CV DAC is updated over SPI
  • The timer can interrupt the main event loop
  • The screen is updated in the main event loop
  • The screen is updated over SPI
  • Ergo, CV updates can interrupt screen updates, causing screen corruption (but it doesn’t cause any issues with CV generation).

At the time, I decided that we’d finally gotten the Teletype firmware to the point where is was very stable, and we’d finally understood why it was crashing when it did. I didn’t want to risk that stability by having to tackle the issue of locking access to the SPI bus.1

@scanner_darkly was looking at it though. He has a fix for the issue on the master branch of libavr32, but that requires changes to be made to all the modules to be made compatible. So far only Earthsea has been updated. I think there is a branch on his repo with the changes made to Teletype too. Things are hazy though (baby brain…), there are some threads on here where we discuss it.

I think either those changes need to be made to all the other modules, or we need to revert them, or do some git shenanigans with branches. At the moment it’s hard for anyway to make any changes to libavr32

1 and I was a bit fearful of doing it too, you mentioned to me how long you’d been coding in C, well… this is the first C I’ve every done! (Though I have dabbled with C++ and Obj-C in the past.)


to clarify, there were 3 separate issues:

  • i2c reliability
  • crashes in extreme conditions (super fast metro script, audio rate triggers)
  • screen glitches / keyboard responsiveness.

only the first one requires also updating trilogy / ansible. for the last 2 only teletype needs to be updated. there is no requirement to update everything to the latest libavr32 - they should all be compatible. you would only want to update everything to the latest libavr32 if you experience i2c issues.

as a side note, with my changes i got it to the point where i could not get it to crash at all, this is running for over 40 hours with 10ms (could’ve been 2ms, don’t remember now) metro script, audio rate triggers and lots of reading and writing over i2c (ansible and 5 telex modules) in the metro script.


In the 2.1 beta thread, we decided that LAST should take a script number as a parameter so that scripts can check on other scripts, perhaps as a watchdog-type event.

Because of this change, it was decided to add a THIS operator to facilitate checking the current script number.

It was noted:

I found myself commonly using SCRIPT with mods, making for long commands. I think SCRIPT should have a shortened alias because it’s a common place to use THIS, which pushes the text length up quite a bit for a common use case (SCRIPT THIS is recursion).

Maybe a special operator for SCRIPT THIS?

Here’s an idea I had while I was falling asleep, and was wondered if anyone would make use of it:

Based on the concept from LOGO, a turtle is a 2D index that crawls around the patterns as laid out in the tracker. I’m going to use improvised syntax here, but the idea is simple:

@         <--- that's a turtle, it tells you what it's standing on
@.LEFT 1  <--- move turtle left one column
@.DOWN 2  <--- move turtle down two rows
@.WRAP    <--- set wrap mode, walk around the edges
@.BUMP    <--- set bump mode, stopping at the walls
@.BOUNCE  <--- set bounce mode, reversing direction and continuing
@.DIR 90  <--- set the direction to 90 degrees
@.FWD 3   <--- move 3 units forward in the current direction
@.TURN 45 <--- turn 45 degrees clockwise
@.X 1     <--- jump to column 1
@.Y -10   <--- jump to the tenth to last row
@.POS 1 1 <--- jump to position 1,1 and set as home
@.HOME    <--- jump home
@.SHOW    <--- show the turtle on the tracker screen

Even if nobody likes it, I’m doing this for my private branch to make arpeggiators. :slight_smile:


Turtle sounds fantastic (love the use of @). It will be very easy to create Rene-style voltage maps.


Hahah, my first programming experience was Logo lessons when I was a kid…
I like this very much.


Whoa, Turtle just gave me a crazy idea. Probably a bit silly and labor-intensive.

I’m imagining a way to attach a Grid to the Turtle, so that you can display the active step on the Grid and use the Grid to potentially set the Turtle’s next location.


Buttons to control the turtle, I love it!


This would be amazing. @scanner_darkly was working on some grid+TT action a while back.

It would be cool to be able to set the step using the grid and then set a DRUNK condition to have it amble its way to it.


Grid Interface idea:
The top four rows are the four tracker columns rotated on their side. The brightness of each button corresponds with the value of that location (might be too complicated with the huge range of useful values and purposes)

In the bottom four rows:

  • A small D-pad for manual piloting of the turtle
  • Four buttons to select the active page (since there are 16 visible steps and 64 possible)
  • Elements for controlling the active range of the turtle (if you just want a 4x4 for instance)
  • Maybe something to change between WRAP, BUMP and BOUNCE


I love this idea. Logo is so special, and I can see wanting to do this with pattern data all the time.


I love this idea! I worked on something similliar within the current operator set but did not get to nice solution by now.

I wonder if @.DIR X would have ha a default setting/direction so you can start with a predefined direction or set it before starting. Something like it will always start going downwards unless you start or initialize it with @.DIR X to have it move in another direction?

I think a grid display solution for this is a nice idea, also with additional controls on the free space. Though they should work in realtime then while teletype is event based by now.

Rotating the four tracker columns to the side would mean that the first tracker column will be the lowest on the grid and the last tracker column will be the top row on the grid - so the numbers would be reversed. I would find this more counterintuitive than having them mirroring the tracker view with a bit of scrolling if you really want the turtle to live in something bigger than a 4 x 8 grid.

How about staying with the screen and using four keys to change the direction - like Alt + ?


First, i must say i’m in awe regarding all the hard work, dedication and imagination this module has gathered. It’s really a great thing to see this ecosystem grow.

Owning a TT myself and having no coding background, i’ve only made baby steps with it, with much pleasure i must say in each case! So a lot of the technical discussions here goes beyond my head. If the point of view of a “basic” user is useful here, i would like to point out a few things (and sorry if my post is not that much relevant!) :slight_smile:

  • The tutorials and studies are an incredible learning tool, and it goes beyond learning the code : it drives you to think differently about performing, about composition etc.

  • For the same reason, i must say that as a basic user i’m overwhelmed by what is going on in V2 and didn’t dare too update yet as i am not feeling confident enough with the new things… As the docs are in constant evolution and the forum topics are filled with implementation discussions, i think new tutorials are greatly awaited to convert what we can understand of new ops, into what they can mean in musical contexts… Can’t wait too see and study new ones. At the moment i think (maybe i’m wrong) updating would mean too much investment and a learning curve too steep for the time my job and family leaves me for it.

  • Lastly, i remember (but maybe i’m mistaken), that tehn talks in an early topic on V2 about Midi ops. I must say that this is high on a personal features request list for the TT ; i use some time Ansible as a Midi converter and it would just be a dream to have MIDI ARP OP in TT, or MIDI CLOCK OP for example, with rate, direction, division, etc. under TT control. The TT shouldn’t only be open “from the inside”, by extending its own power and capabilities, i think it should also open itself to other machines, following the path of TT remote for the trilogy, the Telex expansion etc.

Any way, that was my 2 cents!