Teletype 3.+ feature requests and discussion

[adrianf]

Thank you for all these cool new delay ops. I’m trying them out right now.

I’m trying to understand, if I type the following:

$ 1
DEL.X 4 BPM / 120 4: TR.P 1

I should see 4 triggers at 120 bpm

and if i type:

$ 2
DEL.R 4 BPM / 120 4: TR.P 1

I should see 3 (A minus 1 delays by B ms) triggers at 120 bpm?

I think i see/hear 4 for DEL.R 4 (the same as DEL.X)?

I could very well be misusing this new op.

edit: DEL.X delays all trigs, DEL.R ignores the first delay, and applies delay to subsequent trigs.
I was misunderstanding the op.

[alphacactus]

ya first command has a delay of 1ms for del.r. I’m guessing it’s a typo, but you have the number of delays in there twice? just noting number of delays should be the first parameter.

[ether]

Next level USB Storage Ops

Ability to bring up a directory listing of *.txt files on the root of the USB stick and select one to load into a memory slot without having to use a computer to rename it. Possibly an option to save current scene only to USB? Ability to name it something other than ttxx.txt?

Big +1 from me for that

[laborcamp]

Shadow scripts!.. (basically another set of scripts doubling the amount to 20)

Some sketches for interface visual indicators that you are in shadow script, which I did a while ago in another thread.

[adrianf]

Beautiful mockups. I hope to see a timeline and/or shadow scripts someday too!

[scanner_darkly]

Next level USB Storage Ops

related thread: (Teletype) USB Disk Mode Interface

calling SCENE does reset grid ops, I think?

not home right now so can’t check, but looking at the code SCENE shouldn’t reset grid controls. if it does i’ll definitely fix it to be consistent with how it works for other things. you know, it never occurred to me to use SCENE as a way to go beyond 10 scripts! it can make scene sharing more complicated but the benefit makes it worth it. and this could be a good way to implement a more complex grid controller for, say, er-301 where you could have a set of controls shared by all scenes, and each scene can customize how those controls are used.

[EqualTemperament]

not home right now so can’t check, but looking at the code SCENE shouldn’t reset grid controls. if it does i’ll definitely fix it to be consistent with how it works for other things. you know, it never occurred to me to use SCENE as a way to go beyond 10 scripts! it can make scene sharing more complicated but the benefit makes it worth it. and this could be a good way to implement a more complex grid controller for, say, er-301 where you could have a set of controls shared by all scenes, and each scene can customize how those controls are used.

I did a small test and this is what I found. I’m running the most recent build that @alphacactus posted in this thread. Teletype 3.0.0 267A22F

Scene 6
I:
G.BTN 1 0 0 8 8 0 3 1
SCENE 7

Scene 7
1:
IF EQ 1 G.BTN.V 1: TR.P 1

If scene 6 is loaded from the keyboard (ESC, [] to Scene 6, ENTER), then the button displays but SCENE 7 is not loaded. This is the same behavior if scene 6 is loaded from the grid ops controller.

If after loading scene 6, the INIT script is re-run by pressing F10, then it proceeds to scene 7. The grid ops button remains intact and triggers script 1 in scene 7. Same is true if you run INIT manually from grid integration.

Finally if you change it so that SCENE is called from a numbered trigger script instead of INIT:
Scene 6
I:
G.BTN 1 0 0 8 8 0 3 1
SCRIPT 1

1:
SCENE 7

then calling scene 6 from the keyboard or grid integration proceeds to scene 7 with the button intact, and firing scene 7 script 1.

I’m not sure if it’s expected behavior that calling a SCENE op from INIT doesn’t do anything or not… I mean it does but only if the script is run manually and not as part of scene load.

But yeah, using this technique, you could theoretically have at least 9 scripts for set up kinds of things, leaving all the scripts in a called scene open for reacting to events. Possibly you could get even more scenes of set up but you’d have to trigger the 2nd set up scene’s INIT manually with an F key or grid integration, I think, since a scene called with an OP won’t run INIT automatically.

I hadn’t thought of but do really like your use case where a single scene sets up a consistent set of grid objects, then you can call many possible other scenes to have the familiar objects do different things.

EDIT: Kind of a caution here though - I think in the final config, I have blocked myself from ever editing Script 6 which may be why it doesn’t load the scene when INIT is run at scene load. Probably need to read the parameter knob to evaluate whether you want to edit or proceed to the next script.

[scanner_darkly]

this sounds like a bug to me (although perhaps there are some specific reasons for why SCENE shouldn’t work from the init script).

re: the init script not executed when SCENE is used - it sorta makes sense. if you have a multi scene set up your script will likely switch between different scenes multiple times, so you probably wouldn’t want them reinitialized each time. on the other hand, it would be useful to have a script that gets called each time a scene is called with SCENE. so yeah, maybe a separate op that gives you this option?

not being able to edit - that’s an interesting side effect ) and yeah maybe it’s the reason for how it works now. i guess you could just use SCENE to load it in this scenario. if we change SCENE behaviour then a different shortcut could be added for scene loading (like shift-enter) indicating you don’t want to execute the init script after it’s loaded.

[EqualTemperament]

I like the idea of shift+enter to load a scene without executing init. I know there are lots of people who would like to see more/phantom scripts and/or timeline (me included). It seems to me like that’s going to be a pretty major enhancement, and I’m not sure I’ve seen any devs jumping up and down to take it on.

Using this SCENE technique, plus the new local variables opens up a lot now. This + some improvements to the USB storage mechanism to make it more dynamic without a computer, I think, would open up a ton. I read through the linked thread on USB Disk Mode interface and had to smack my forehead and say “derp!” when I realized the keyboard and storage media couldn’t be connected at the same time. But the proposed menu system looks really good!

Is there already a list somewhere already of what’s preserved vs. reset to default when a scene is called using the SCENE op? Or if not would it be worth me spending some time to document it? This is not a comprehensive list but I’m just thinking about things like:

• grid ops objects
• global variables inc. things like (O, DRUNK, etc.)
• local variables
• CV.SLEW and CV.OFF (inc. things like TO, JF, SC)
• TR.TIME
• pattern data itself and P.START, P.END, P.L, P.N

[scanner_darkly]

yeah, i think adding a section on this to documentation would be great and would help to ensure it’s consistent. i’ll try to find the time to document it when i get a chance.

[alphacactus]

not home right now so can’t check, but looking at the code SCENE shouldn’t reset grid controls. if it does i’ll definitely fix it to be consistent with how it works for other things. you know, it never occurred to me to use SCENE as a way to go beyond 10 scripts! it can make scene sharing more complicated but the benefit makes it worth it. and this could be a good way to implement a more complex grid controller for, say, er-301 where you could have a set of controls shared by all scenes, and each scene can customize how those controls are used.

not sure if this was resolved, but flash_read(called when by the SCENE op) would write the grid ops saved by flash_write with the unpack_grid and pack_grid calls. I’m not entirely sure what unpack_grid and pack_grid do, but this may be the cause of this behavior.

[EqualTemperament]

Calling a scene with the SCENE op does not reset grid ops objects, which is the expected behavior. Sorry if my wording was confusing.

[scanner_darkly]

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).

[freqout]

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.

[freqout]

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!

[adrianf]

Hi, I think this post is relevant:

Teletype workflow, basics, and questions

i implemented it this way because then you can control both the start and the end point of the range you select from. as a side note i find having both P.END and P.L just creates confusion, but as it’s the existing behaviour it has to be supported. but for P ops that deal with range it makes more sense to use P.START and P.END as the range definition.

[Starthief]

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

[scanner_darkly]

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.

thoughts?

[josker]

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

[freqout]

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