(Teletype) 2.2 Release



PARAM.SCALE is great.
One question though, is it normal that PARAM.SCALE 1 16 results in a maximum of 15 ?

CHAOS Operators

Before executing PARAM.SCALE, does your PARAM go all the way to 16383?

There is a bug in Alpha 3 it seems, as I’m scaling to 16384 not 16383, but that won’t make a difference if your PARAM value doesn’t go all the way.

PARAM.CAL.MAX and PARAM.CAL.MIN are on the way and will solve this problem, I’ll make bugfix at that time.


Great. Mine goes up to 16340 only.


Yeah, I am seeing slight inconsistencies with PARAM.SCALE as well.
For example


yields values between 0 and 23


Same comment as above. If your naked PARAM at fully-clockwise does not reach 16384, then the maximum value yielded by a scaled PARAM will be off-by-one.


Yup, my PARAM on it’s own seems to slightly fluctuate between 16320 and 16336.

Teletype 3.0

thread recategorized to Development


My screen never goes fully blank. The only thing that happens is the message “Teletype 2.2.0-Alpha.3: 2424CFF” disappears, but the prompt and top right corner symbols and text are always visible.


Thanks for the report! This turned out to be excessive sensitivity in sampling the knob value. Fixed in…

Alpha 4

teletype.zip (120.6 KB)


  • Fixed buffer overflow in version string display
  • Reduced knob sensitivity for screensaver wake


Alpha 5

teletype.zip (120.6 KB)


  • Fixed bug when changing scripts in edit mode with alt-F1 et al.


Alpha 6

teletype.zip (121.3 KB)


  • Implemented new calibration operators
PARAM.CAL.MAX             | set and return param max
PARAM.CAL.MIN             | set and return param min
  • Same set of operators for IN

Example PARAM Calibration

  1. Turn knob fully counterclockwise
  3. Observe the value
  4. Repeat step 2 several times to understand jitter
  5. Turn knob fully clockwise
  7. Repeat step 6 several times


  • Calibration data saves across reboots
  • Calibration data is cleared whenever new firmware is loaded

(Teletype) IN / PARAM Calibration (Done)

Alpha 7

teletype.zip (121.4 KB)




Feature Change

As the USB filesystem rewrite will require copious testing, I’m going to push it back to version 2.3, where it will be the first and likely only feature that I add.


That’s super nice ! thanks !


After careful consideration, I’m withdrawing my support for turtle step quantization (@QUANT, discussion starts here).

It’s actually not a very easy problem to solve as I had thought, and 100% of the functionality is already present in @MOVE.


Once I finish the State Clearing Operators (awaiting feedback), I will put a bow on the alpha phase of 2.2. I hope to get that done within the next week, so consider next week the start of the beta test phase. With luck, we can have 2.2.0 out by December.

During the beta, I will need a few good testers to put this feature set through the ringer, but – good news! – because I’m following a sane development cycle, you can expect no wild feature additions, only bugfixes and feature adjustments. Should be smoooooth sailing. :crossed_fingers:


has anyone been beta-testing this build?

i’ll head over to the state clearing ops and make some suggestions now…


Impossible, as I have yet to go to beta!

Beta will be posted once I finish up moving CA out of CHAOS and implementing INIT. Monday?


ran into a potential bug, but not sure if it’s indeed a bug or expected behaviour - if you do something like:

I 4
DEL 10: TR.P I

it doesn’t output a pulse. this is likely because I is now treated as a local variable. would it make sense for DEL (and stack as well i guess) to use the value of I as it was at the time DEL was executed? but then this wouldn’t work for other variables, so maybe we just leave it as is…


In fact, right now, I only makes sense in an L sub-command.

Nevermind, just read the code and that assumption is incorrect.