Teletype 3.+ feature requests and discussion

strange, there must be some significance to the value but at a glance i’m not sure what exactly. and strange it wouldn’t work properly with a single address. i have a feeling there might be something else going on as a single read from a single app should be pretty reliable. just to rule out the op itself not being defined properly, could you try running the tests?

i haven’t thought of that - entirely possible. are you seeing the issue with just ANS.APP or others as well?

agreed, i think this makes sense.

Hm, getting an odd compile error here even on master. I’ve been building both Ansible and Teletype firmwares with this Docker image, e.g.

$ git clone --recursive
$ docker run --rm -it -v "$(pwd)/teletype":/target dewb/monome-build bash
root@586fef5bc691:/target# cd tests && make clean && make test
rm -f tests
rm -rf tests.dSYM
rm -f *.o


cc -o tests main.o log.o match_token_tests.o op_mod_tests.o parser_tests.o process_tests.o turtle_tests.o ../src/teletype.o ../src/command.o ../src/helpers.o ../src/every.o ../src/match_token.o ../src/scanner.o ../src/state.o ../src/table.o ../src/turtle.o ../src/chaos.o ../src/ops/op.o ../src/ops/ansible.c ../src/ops/controlflow.o ../src/ops/delay.o ../src/ops/earthsea.o ../src/ops/er301.o ../src/ops/fader.o ../src/ops/hardware.o ../src/ops/justfriends.o ../src/ops/meadowphysics.o ../src/ops/metronome.o ../src/ops/maths.o ../src/ops/orca.o ../src/ops/patterns.o ../src/ops/queue.o ../src/ops/stack.o ../src/ops/telex.o ../src/ops/variables.o ../src/ops/whitewhale.o ../src/ops/turtle.o ../src/ops/init.o ../src/ops/grid_ops.o ../src/ops/matrixarchate.o ../src/ops/wslash.o ../src/ops/seed.o ../libavr32/src/euclidean/data.o ../libavr32/src/euclidean/euclidean.o ../libavr32/src/util.o ../libavr32/src/random.o -std=c99 -g -Wall -fno-common -DSIM -I../src -I../libavr32/src
 (No such file or directory)
Makefile:33: recipe for target 'test' failed
make: *** [test] Error 2

All the files listed in this cc command do exist at this point in the build, as does the greatest/greenest script and /usr/bin/awk, so not sure what file it’s talking about, but I do notice that interestingly this lists ansible.c rather than ansible.o. Changing that gives the same error.

1 Like

yeah, should be ansible.o, looks like a typo in makefile.
sent you a PM, let’s move dev discussion there!

1 Like

I’m going to try and make my first button interface, today. Sort of mimicking a Lorre Mill Keyed Mosstone. Getting ready I’m wondering if it would be possible to add one more param to the G.BTX? I know there are many, many already, but here’s my thinking. If we could define spacing between objects, like buttons, we would be able to more easily create multiple groups of similar, but not the same (eg alternating level so adjacent buttons can be identified more easily). Or, if space was not at a premium, separation between objects could make the UI more easily readable.
BTW - I’m really just getting started with this - is ‘objects’ the correct term for buttons, faders, etc?

Okay, I fixed a bunch of issues that arose from my misunderstanding of managing Teletype command state, wrote help entries, cleaned up debug prints etc. You can also now read whether a grid key is held with ANS.G x y. If anyone gets a chance to test this out, especially the Arc ops, that’d be great – other than those I think this is pretty much ready to PR.

New Ansible ops:

ANS.G x y / ANS.G x y z   # get/set grid key state (z) at pos x, y
ANS.G.P x y               # simulate grid key press on ansible at pos x, y
ANS.G.LED x y             # get grid LED state for key x, y
ANS.A n d                 # simulate arc encoder rotation of ring n, delta d
ANS.A.LED n x             # get arc LED state for ring n, LED x (clockwise from north)
KR.PG / KR.PG x           # get/set active kria page
KR.CUE / KR.CUE x         # get/set cued pattern

Edit 5/4/2019: added KR.CUE

teletype.hex (575.6 KB - 3f801f7)
ansible.hex (247.9 KB - b804114)


yeah, these ops are very parameter heavy already, so adding 2 extra parameters would be difficult. one potential solution could be adding ops to change control’s width or height, i’ll consider adding it.

“grid controls” is the term i use to group all the different possible controls (buttons and faders for now but possibly more in the future). (side note - this thread is a better place for grid ops related questions/suggestions).


My requests for new firmware are:

  • More lines per script
  • More varibles

There is a long discussion of this very topic here: (Teletype) expanding scripts: length and amount with very interesting insights from both sides (also some neat tricks, tips, and workarounds).


So, I’ve been spending more time with my IME Stillson Hammer mk2 again lately after neglecting it when I got a Grid + Ansible (Kria). I’m not really sure if these fit more into TT op requests or Ansible/Kria feature requests. I could see them being implemented in either place, but I figured that you’re all much better at TT than I am, so maybe you have some suggestions. I know some of these things might be possible with grid ops (eg: I’ve seen @scanner_darkly do some random generated stuff, iirc).

A couple things from the SH2 that I’d love to be able to do in Kria, either directly in Kria or via TT, are:

More clock/step selection options: So TT now has the ability via KR.CLK to advance a step on a channel in Kria, but it’d be great to be able to have other directional modes accessible. Forward, backwards, pingpong, random and drunken/brownian. Some of these could probably be reasonably easy to script simply if KR.CLK had a second argument where you could specify how many steps to advance and/or supporting negative clock values.

Random pattern generation: I enjoy being able to randomly generate cv, gate, etc values on the SH2. It’s great for live improv stuff. I know I can easily just mash buttons on my grid, but somehow that’s not as interesting, possibly because it’s slower AND feels less random (humans aren’t good at true random).


in the mean time I’d check out KR.POS! In combination with KR.LEN, you can really get super inventive with how to address steps of Kria. It definitely takes more thought (and script lines) than a backwards clock, but all of what you said are possible today.

I’m happy to help with snippets of scripts to accomplish this too, if you’d like.


How did I miss that?! :man_facepalming: Thanks!

1 Like

You may wanna check the developments in Ansible Kria Feature Requests!

Would it be feasible for Teletype to automatically poll and pass through FB to SC.CV, without needing to script it? E.g. my default scene looks like this:

L 1 16: SC.CV.SLEW I 25 
M 25 

L 1 16: SC.CV I FB I

It’d be nice to just issue “FB.THRU 1” to take care of it, and then still have the metronome available (and two precious lines in I, for those who use I more than I do).

it wouldn’t fit the teletype model very well, since it’s based on discrete events, not continuous processing. doable, but several things would need to be considered:

  • this could potentially affect the overall performance (depending on how often it runs)
  • this could affect performance of i2c ops
  • what if you want to send it elsewhere? this would require a separate op to specify the destination

so in general while using metro script for this might not be ideal it does give you more flexibility in terms of how exactly it’s done. personally, i think a second metro script would achieve this better while also supporting many other use cases. but that’s a bigger discussion…

1 Like

tt devs - as @tehn suggested, let’s release what we’ve added since 3.0 as 3.1 version.

@alphacactus @csboling - anything outstanding that needs to be merged? i think ANS.# ops, some new kria ops, i’ve got SCENE.G, anything else i’m forgetting?


nope, all good on my end

1 Like

Yeah ANS ops, KR.PG and KR.CUE from me. Would also like to maybe add KR.DIR for the new direction modes, and any other Ansible remote ops that are quick to add since these require merges to 3 different repos. I won’t be able to work on this for a couple days but will try to PR everything by the end of the week.


submitted my PR for SCENE.G - this is the only change i have for teletype.


Please make sure the support for all the keyboard type is included in 3.1: it really made a huge difference in my use/experience. (And thank you for developing/addressing that in the first place!)

1 Like

I believe this was merged shortly after the last release.