Teletype 3.+ feature requests and discussion


not sure where tilde came from actually but i think tilde is when you press with shift, the actual key is back apostrophe. try using the key without shift


Fixed. On the off chance that someone else is having the exact same (very specific!) issue - i.e. the tilde sent from an OLKB Preonic keyboard is interpreted differently in the A235649 build than in 3.0 build and so no longer displays the live variables page, the fix is to re-flash the keyboard to use the KC_GRAVE key instead of the KC_TILDE key for the tilde.

1 Like

so do you use shift with it?
it’s super strange it works for you with 3.0 but not this beta. that part of code wasn’t touched, the only change was a fix for vortex keyboards but that doesn’t change how keys are interpreted.


It does seem pretty odd. As far as I can see here, it’s actually the grave accent symbol that’s displaying the live variables page - i.e. the other symbol on the key under the ESC key on the default keyboard that came with TT:


If I hit this key using the default keyboard, the live variables screen is toggled. If I hold SHIFT and hit this key, the screen displays a tilde.

My OLKB keyboard doesn’t have this key, so I’d configured the keyboard to use a key combo to generate a tilde. The key combo included a SHIFT - because the tilde is the shifted character on that key.

I’ve removed the SHIFT from that key combo (i.e. I’m sending a “`”) and all is working as it should.

What now seems strange to me is that it worked for me in the 3.0 build. :stuck_out_tongue:

1 Like

yeah, what you describe makes sense, other than the fact it somehow worked with 3.0. tilde is when you press that key with shift. teletype displays tilde, as expected, when you do. so the correct key for live variable display should really be grave/back quote.

i see where the confusion with tilde comes from - ASF code actually names the key HID_TILDE, which is incorrect.


posted new beta (see the op). added the following:

(huge thanks to @alphacactus!)

SCENE.G op - load scene without initializing grid controls


Fantastic! Does SEED set the seed for every random number including all the other new SEED ops? Ie Would it override a previously set PROB.SEED? (EDIT: I see I asked this back when SEED was first introduced and @alphacactus confirmed)

Thanks so much for this. I’ve used SEED in every single patch since @alphacactus first build. It’s so useful - and now it will be possible to tweak interesting loops of randomness.

EDIT 2: Testing now. Looks like R.SEED is implemented as RAND.SEED? What does P. SEED set? I thought it would set the working pattern.


ya there are a few aliases for each of the seed ops. P.SEED sets the seed for the P/PN.RND op.



Aha. All makes sense now. R.SD is very succint! Thanks for your work!


What does SEED mean?


@Leverkusen computer-generated random numbers come from algorithms which are not actually random, so it’s important to feed these algorithms with a good source of randomness to “jump start” them. hence the “seed” values. but if you use a known seed then you will get a known result. in other words, you can use the SEED OP to retrieve a predictable string of results from the related OPs.

1 Like

Thank you for pointing that out! So the idea is that a certain random behavior can be part of something like a preset, or scene in this case?

What data does the SEED expect? A single number? A row of numbers? You can guess that I have no idea how this actually works behind the scenes and what kind of algorithm is working the random result out. Is it a bit like the CHAOS functions @sliderule implemented in the 2.0 firmware?

1 Like

SEED only requires a single number. for example if I were to do SEED 101 then call RAND 5 three times I might get a sequence like 5, 2, 3. then if once again did SEED 101 and called RAND 5 three times I would get the same sequence 5, 2, 3. so you only need to call it once with a single number, but each time you call it with the same parameter value you will repeat/restart the random sequence.


I’ve noticed an issue where if I switch back and forth between keyboard and grid (with grid control mode active)., and I have a script going with the metro acting as the clock, the clock will have a laggy beat (as I guess it loads things on the grid) causing things to slow down for a second.

If it’s possible to have the audio loop maintain “preference” (and grid control mode take longer to load if necessary) that’d probably work better in my particular use case. That being said, I have no idea how difficult or feasible of a change that would be.


it’s likely the fix i applied to ansible will also work for teletype. will try to post a test firmware today.

1 Like
Monome ecosystem firmware development backlog

I’m not sure this is the place, but I have a minor suggestion for the TT firmware: When moving scenes around, it would be nice if the TT would display the “help screen” of the location you’re hovering over, not the one your are about to save. Makes sense?

Teletype 3.0

sorry, just got around to making a test version for you. unfortunately, the fix i did for ansible didn’t really fix the issue for teletype, i’m still seeing an occasional delay. but it’s possible it’ll happen less often now or the delay itself will be smaller, give it a try: teletype.hex.

any further optimization would be difficult i’m afraid, this would require a pretty significant refactoring to have different priority queues. and then a bigger question is - what should take priority? timing accuracy? or responsiveness? these are conflicting requirements - if you give timer higher priority it’ll have better accuracy but at some point you’ll get key presses getting dropped.


thanks! just had a chance to test, and I am hearing no lag.

with M 140 and the M script

TR.P 1

and grid control mode focused on the pattern screen, I toggled quickly between keyboard and grid mode with the TWO:ONE.

The signal I had triggered was audibly rigid on the new firmware, where it used to lag every time the grid control mode screen was switched to and “prepared”.

The only weirdness was after update, the "this will overwrite flash memory screen displayed for a second or two, followed by a blank screen and TR leds 2 and 4 lit. This same behavior was present after a few power refreshes. It went away once I pressed the button in the 1 or 2 seconds the message was displayed.

EDIT: Note that it may be possible there is still a delay with more intense use of teletype I typically do (multiple gates and cv sequences controlled by EVERYs from the internal metro), but I don’t have things set up to test that out at the current moment. I will keep you posted as I prepare a patch for performance in the next coming weeks.

1 Like

re: the message - that’s a new warning we added in 3.+ beta as a way to prevent the issue with flash scenes getting blanked out randomly. you will see this message every time you update the firmware. just press the button as it suggests, and the message will go away. you should never see this message during normal operation (if you do that means you ran into the flash issue - try power cycling teletype and see if the message goes away, and then backup your scenes to USB immediately and let me know).

1 Like

gotcha. I did have a realization I was gonna lose my scenes because I forgot to backup before starting the upgrade (which is fine, nothing is permanent)

But when that message came up the first time, I did attempt to turn off my system, plug my usb drive in, and then turn it back on (which is how I backup normally, if I remember correctly). when I restarted the message showed up for a few seconds and went to the 2/4 LEDS lit with blank screen, the same as if I didn’t have anything plugged in.

TL;DR the backup to usb flow may be broken on upgrade.