Teletype 3.+ feature requests and discussion

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

[alanza]

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?

[josker]

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

EDIT: no it shouldn’t.

[rikrak]

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.

[alanza]

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.

[josker]

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

[EqualTemperament]

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.

[alphacactus]

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.

[apeirophobe]

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??

[desolationjones]

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.

[alphacactus]

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.