#21

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.

#22

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

Teletype 3.0
#23

thread recategorized to Development

1 Like
#24

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.

1 Like
#25

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)

Changelog

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

Alpha 5

teletype.zip (120.6 KB)

Changelog

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

Alpha 6

teletype.zip (121.3 KB)

Changelog

  • 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
  2. PARAM.CAL.MIN
  3. Observe the value
  4. Repeat step 2 several times to understand jitter
  5. Turn knob fully clockwise
  6. PARAM.CAL.MAX
  7. Repeat step 6 several times

Note

  • Calibration data saves across reboots
  • Calibration data is cleared whenever new firmware is loaded
4 Likes
(Teletype) IN / PARAM Calibration (Done)
#28

Alpha 7

teletype.zip (121.4 KB)

Changelog

  • Added (IN/PARAM).CAL.RESET
4 Likes
#29

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.

5 Likes
#30

That’s super nice ! thanks !

1 Like
#31

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.

1 Like
#32

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:

7 Likes
#33

has anyone been beta-testing this build?

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

1 Like
#34

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?

1 Like
#35

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…

#36

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

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

1 Like
#37

I can be used as a general purpose local variable too, right? or you’re talking about PRE specifically?

#38

Yes, it can. I was wrong.

I’ll look into the DEL / I interaction.

1 Like
#39

Looks like I’ll have to stuff I in the delay state. Checked if there were any other candidates to carry over, but it’s just I and SCRIPT number.

Nice find, @scanner_darkly! :+1:

2 Likes
#40

Alpha 8

teletype.zip (122.1 KB)

Changelog

  • Better centering of live mode variables
  • Fixes #130 by carrying I across delayed commands
1 Like