> teletype: grid # code exchange



A[quote=“chailight, post:243, topic:10084”]
One limitation I’m experiencing with my current set up is that when I plug in an actual grid, I get a lot of weird additional triggers out of TR 3 (well at least the Peaks module I’m triggering is registering additional triggers, although I’m not seeing extra LED activity at TR 3 on the TT). I have a new batch TT, so I’m plugging the grid directly into the TT, so I guess this is an electrical noise issue? Anyone else seen similar things?

Weird things happen if you plug a grid directly into Teletype. I’ve had this sort of thing before so I stopped doing it, to avoid damaging Teletype. Best to buy an Offworld https://market.monome.org/products/offworld-1


Thanks @mlogger - I’ve tried using something similar to an offworld (a y-splitter cable that others have recommended) but saw the same issues. Have been doing some more investigation and it may not be a grid related issue after all.

Also, tehn mentioned is this thread that TT itself can’t really be damaged by using a grid directly: Teletype hardware update

but I guess it’s still best practice to power the grid separately, regardless, so that’s what I’m planning on doing from here on.


Yes agreed, what happened to me was I put it in a small 42hp skiff with insufficient power. It did all sorts of glitchy things, sometimes almost powering down with the characters flickering when the grid attached. It also powered off and wiped all the presets and also locked Teletype up. Maybe no damage, but you could potentially lose work if you hadn’t backed up. ( I had backed up so it wasn’t an issue)


@chailight - that’s great, thanks for posting! added it to the code exchange list.

i think you can simplify your grid setup by changing this:

G.BTX 15 0 0 1 1 0 5 0 16 1
G.BTX 31 0 1 1 1 0 5 0 16 1
G.BTX 47 0 2 1 1 0 5 0 16 1
G.BTX 63 0 3 1 1 0 5 0 16 1

to this:

G.BTX 15 0 0 1 1 0 5 0 16 4

and yeah you can definitely pack trigger sequences of up to 16 bits in each pattern value (or variable) - check out BGET, BSET and BCLR ops!

very strange about triggers on TR 3 when plugging in grid - i don’t think i’ve seen a behaviour like this before, even when plugging in directly. does it happen if you try it on a completely empty scene?


odd behavior on TR 3 is a production issue with the latest batch of Teletypes!


somebody should try and decode the noise - it’s probably a hidden message about the NEW THING!


Thanks @scanner_darkly - BSET and BGET look super useful. I can see how I could potentially encode a whole 4 part rhythm with just 4 “magic numbers” stored in the pattern.

For example “King 1” looks like it could be encoded as four numbers: 2741 2741 813 813.

I’ve done some initial experiments around unpacking that kind of info into the grid. For example

L 0 15: G.BTN.V BGET I PN 0 0

seems to work ok in terms of unpacking the first part of the rhythm and with some adjusting for button id’s then the same can be done for the other parts - it starts to get tricky fitting everything into the line length tho!

It took me a while to get my head around the number limits in Teletype. I tried converting a binary number to an integer using a random conversion script that Google threw at me. A 16 beat rhythm might produce a decimal integer value like 37160, which is higher than the upper limit of a TT number storage type, which I guess is technically a “signed short”, rather than a “signed int”.

Once I realised that, then I found a more useful conversion site here:

Playing with that, I started to get my head around it more. if there is a beat on the very first note of a 16 note pattern, the decimal value will be negative.

A pattern like this: 0011010110101101 is encoded as 13741, while
a pattern like this: 1011010110101101 is encoded as -19027

This is stirring some memories of comp sci classes from a long time ago - hopefully my ramblings here have not confused the matter for anyone.

Hopefully I’ll have an updated version with more patterns embedded soon. The current version of the script is obviously much more friendly for every day editing, so I guess there’s pros and cons to both.


teletype numbers are signed 16 bit integers, so the possible range of values is -32768 to 32767. negative numbers are represented using two’s complement - that’s what pretty much every computing system uses, and this is why you get negative numbers if you set the most significant bit: for instance, doing this: BSET 0 15 results in -32768.

when using binary ops (BGET / BSET etc) you don’t have to worry about remembering how two’s complement works, unless you need to convert a binary value (like a drum pattern in your case) to a signed decimal value teletype uses, say if you need to initialize a variable. in this case yeah you can just use an online converter tool, or if you’re on windows you can use the calculator app switched to programmer’s mode. or just use the live screen and manually set the bits with BSET.


axe thing one

For the guitarist in you. Hopefully the video will serve as a quick manual.


axe thing one.zip (3.2 MB)


  • axe thing one.txt is the teletype file. rename it to ttXX.txt where XX is the scene number you want to load it into. copy to your USB drive root, and load on teletype
  • slot1 is an ER-301 quicksave. copy the files in the folder to one of the quick save folders on your ER-301 SD card. then load that quicksave

other notes

  • the ER-301 quicksave comes with 6 acoustic guitar samples inside the quick save folder, so it should load ready to play
  • the first 6 or so default chord presets are in the key of G major. you might have to select a preset button other than #1 to get things started the first time
  • some fun stuff to try would be using something other than acoustic guitar samples, trying some different tunings (e.g. bottom two strings doing bass)


this is amazing!! thank you for the detailed video walkthrough. added to the grid codex!


For some reason when using teletype 3.0 ( I havent tried previous firmware), TR1 aka clock output doesnt follow the clock that I send to input 1. Any idea why that could be happening? It sort of skips certain clock pulses, but stays in sync. Maybe the issue is with the clock pulse width?


it sounds to me like TR.TIME 1 might be set longer than the time between clock pulses coming in?


are you seeing something similar to this? Teletype dropping TR.P -- with video :-)
i’m planning to look into it when i get a chance.

edit: actually not sure that’s related. could you describe what happens exactly and post your script?