Teletype 3.+ feature requests and discussion

when you define grid controls (with G.BTN / G.FDR and their variations) that definition is not stored to flash. you have to set them up in the init script. what is stored to flash is grid button states and fader values. this is so that if you, say, use grid buttons as a trigger sequencer, then your sequences will be stored when you store the scene to flash or usb (unpack_grid and pack_grid serialize it so that it takes the least amount of space).

now, if you have some grid controls defined and you load another scene from flash it will reinitialize all controls and hide them. but when SCENE op is used it will not do this, which sounds like exactly the behaviour we want (as it will allow creating grid scripts that could span multiple scenes).


I think comments in scripts have been discussed before, but I was thinking it might be handy if comments corresponded to lines and holding a hotkey down would reveal the comment. Kinda like as if you were flipping that line of code around to see an annotation on the back of it. That way comments don’t require additional lines and can correspond directly to a script statement.

Also, was there ever any ideas about the confusion inherent in P.L and P.END? I almost never even touch P.END, but now I see that we’ve got P.RND, but it only accounts for P.END and not P.L! :dizzy_face:

Hi, I think this post is relevant:

1 Like

I’m a bit late to the testing party, but I just installed the beta 25E14EE (.hex from November 3).

To hopefully avoid some confusion for anyone else:

DEL.X x y: creates x delays with y milliseconds between them
DEL.R x y: executes the code after the colon immediately and creates (x-1) delays with y milliseconds between them

Some of the initial posts about XDEL had said x was the time and y was the count, but it’s the other way around :slight_smile:


there was a timing issue reported on orthogonal devices forum. basically, when using metro script to output a pulse to er-301 and using it to clock a delay there was noticeable warble when switching modes on teletype.

this is likely due to the fact that teletype stores the latest mode to flash, so that it starts on the same page when booted up. so when you switch modes it introduces a delay while it writes to flash.

i did some measurements to confirm the issue. a simple scene with metro outputting a pulse on one of the gate outputs at 100ms rate was used. each measurement was based on a sample of 1000 pulses.

without switching modes:
min: 99.06 max: 100.3 average: 99.85 stdev: 45μs

switching modes [very roughly] every second:
min: 99.60 max 102.7 average: 100.6 stdev: 172μs

i then commented out saving to flash.
to confirm nothing else was changed i repeated the test without switching modes first:
min: 99.06 max: 100.3 average: 99.84 stdev: 56μs

switching modes:
min: 99.06 max: 101.5 average: 99.84 stdev: 83μs

since it also needs to update the screen and there might be additional setup needed for each mode i also tried switching between scripts:
min 99.06 max 100.3 average: 99.85 stdev: 48μs

so, saving the last mode to flash definitely has an effect. the question is - is it significant to be fixed? personally i don’t think anybody expects teletype to be super precise with timing, but if it does affect its use in a musical context then improving it should definitely be considered, especially if there is an easy fix for it. saving the last mode seems like a nice to have, not a must have. the only practical application for it i can think of is where you use teletype with one scene and don’t even plug keyboard or grid into it, and you want to see a specific screen. but that’s such an edge use case. with keyboard/grid it’s very easy to switch to the screen you want, and it does not affect teletype operation otherwise when you boot it up.

an alternative to the current implementation could be saving the last mode when you save a scene.



Is this a bug, or something I’m overlooking:

PROB 30: BRK; SC.CV 2 RND 999

results in the 301 value not changing. Once I delete the “PROB 30: BRK;” part, the SC.CV 2 part immediately starts working.

And yes, I gave it some time :smiley:

BRK immediately abandons execution of the rest of the script so it’s working as it should.

1 Like

Sorry, misunderstood the source of the error: when PROB: 30 fails, the rest of the line does not execute, not just until the semicolon. Perhaps you could try PROB 70: SC.CV 2 RND 999?


But shouldnt the PROB modifier allow the script to run its course 3 times out of 10?

EDIT: no it shouldn’t.

I would vote to remove the mode saving altogether, personally. If I was playing live, or making a recording, having the mode-switching have an audible effect would stop me from using the 301 over i2c.


No, 3 times out of 10, the line calls BRK, which stops the script. 7 times out of 10 it skips the line, meaning BRK and the following statement on the same line are not executed.


OH! So no bugs to see here. Thanks so much, and sorry.

1 Like

Agree with @rikrak. I didn’t even realize it was recalling the last mode, so I won’t miss it. Saving it only when the scene is saved would also work.


yes this is correct. original idea was to keep the syntax similar to DEL with the first parameter as the delay time. however, I later decided with the name DEL.X that the x parameter should be the number of delays.

still unsure what would make more sense, but I think an update to the docs with descriptive parameter names should remove the confusion.


I’m having an issue with the new DEL.X / DEL.R commands. If I call script n in a loop and script n uses one of the new DEL commands then it seems that only the last DEL is executed. Is that true or maybe I am screwing something else up??

How many delays are you instancing? There’s a limit to the delay queue length; used to be quite low. I know it’s been increased for the new DEL.X mod but I don’t remember what the new number is.
Pure speculation: it’s possible your newest delays are pushing the older ones out of the queue before they have a chance to activate.

posting the script could help pin down exactly what’s happening. but I’ll list a few of my thoughts on what might be happening.

  1. as mentioned there is a limit of 16 delays
  2. L 1 4: SCRIPT 1 will call the script 4 times without much delay time between calls. so if the delay time isn’t changing then it’s possible the delays are being queued to trigger at the same time.

Sometimes, when I’m running out of empty scripts and/or lines and I need to perform the same operation on each of the four patterns in the INIT script or another script, I wish there was a kind of P ALL OP -> PA maybe.

Instead of:

L 0 15: PN 0 I I
L 0 15: PN 1 I I
L 0 15: PN 2 I I
L 0 15: PN 3 I I

It could be something like this:
L 0 15: PA I I

As far as I know it’s not possible to use L twice on the same line
L 0 3: PN.WRAP I 1; L 0 3: PN.L I 16;

So, PA.L 16; PA.WRAP 1

Not sure if that would be a gadget or not :slight_smile:

It doesn’t actually help, but you could write

L 0 3: A I; SCRIPT 3

and then in Script 3 do the inner loop

L 0 15: PN A I I

OMG! I figured out how to do it in one script (suppose this is script 3)

IF > 3 A: A 0; BREAK
L 0 15: PN A I I
A + A 1; SCRIPT 3

One problem I see is that if you want proper behavior, you either have to trigger the script twice, or set A to zero in the calling script.

It’s also possible (quite likely in fact) that I’m trying to be too clever and that we could achieve the same goals with the Turtle ops