#41

Does this build include the Grid ops ?
I’m really into programming for the grid, but i’m missing the display of variables.

#42

Would this mean that you couldn’t use ‘I’ in a different script for the duration of the delay? Or would the value of ‘I’ remain locally?

#43

Typing PARAM at full clockwise on Alpha 8 I only get 16383 and never does it go to 16384. Reading the rest of the thread I don’t see where that gets resolved?

This can be deleted as after I ran Param.Scale 0 16384 it all became obvious what needed to be done and how this works.

#44

Negative. You’ll have to rely on @scanner_darkly to produce those builds, and he can’t merge in the 2.2 features until they’re stable.

Nope. I is local to a script and execution state. To explain:

#1
I + I 1
A

A will always be 1. Each time you call this script, I is 0.

Is it supposed to go to 16384 or 16383? I changed it to 16383 by default after I read the teletype docs, and I’m pretty sure it says it’s supposed to be 16383.

1 Like
#45

I should probably steer clear of this thread unless I’m certain about what I’m doing. In the Teletype studies I got to the page with PARAM and remembered something from this thread. In my novice understanding I thought it said above that it was supposed to be 16384. Okay so naked PARAM reads 16383 while PARAM.CAL.MAX is reading 16340. I’m too new to this yet and should wait for proper documentation before pestering the devs.

#46

After you call PARAM.CAL.MAX, your new calibration is set. The next call to param should be 13683.

Here’s an example:

> PARAM.CAL.RESET
> PARAM => 16340
> PARAM.CAL.MAX => 16340
> PARAM => 16383
#47

Thanks, I feel better knowing this is calibrated correctly. BTW, I can’t wait for you and @scanner_darkly to merge 2.2 and the Grid Ops version. For a minute and a couple of times I had to check and recheck if I was spelling PARAM.CAL.MAX correctly before I realized which firmware I was running :slight_smile:

1 Like
#48

Thanks for that, I understand that side of the behaviour but was unsure how it would be stored during the delay - whether it would be separate for each script (I suspect) - I guess this is the problem you’re solving!
I guess in that case, in theory, you could have multiple scripts executing Delay scripts with I in parallel and each script would keep it’s own value of I without affecting the others. Unlike with other global variables which, in a delay command call on the variable after the delay time, rather than at the start of it. (I’ve started messing around treating other variables as local variables… :slight_smile: )

Anyway, thanks for all the work you’re putting into Teletype. It’s really appreciated.

1 Like
#49

It’s more accurate to say that: each time a script is called, I is 0. The value of I is captured when a command is delayed.

1 Like
#50

Alpha 9

teletype.zip (123.8 KB)

Changelog

  • Added INIT operators

    INIT               | full init             
INIT.SCENE         | same, for now
INIT.TIME          | init all time parameters
INIT.DATA          | init all variables
INIT.SCRIPT N      | clear script N
INIT.SCRIPT.ALL    | clear all scripts
INIT.P N           | clear pattern N
INIT.P.ALL         | clear all patterns
INIT.CV N          | clear cv + parameters for CV N
INIT.CV.ALL        | clear all cv + parameters
INIT.TR N          | clear tr + parameters for TR N
INIT.TR.ALL        | clear all tr + parameters

This is a first stab at the behaviour, so I expect to have forgotten something, but all the commands work as I expect for right now.

Trying out a thread title with no (Teletype), but with a tag.

3 Likes
#51

My favorite operator ever! As I’m seriously new to all of this I do a lot of backspacing and entering blank lines to remove scripts I’m experimenting with. Having a single INIT command to erase all six lines is a dream. Thanks.

1 Like
#52

Alpha 10

teletype.zip (125.3 KB)

Changelog

  • Added R, R.MIN, and R.MAX (programmable RNG)
  • Added profiling code
7 Likes
#53

I’m afraid that I haven’t found the time to integrate the CA changes yet, as I have been busy with sysadmin work.

If someone else wants to take a stab at it, message me. Otherwise, it will be a while before I can get to it.

#54

I haven’t tried this yet. But looking at it, INIT seems a bit destructive. Can there be any safe measures before its execution? I suppose a confirmation dialog may not be very Teletype style. How about having to issue the INIT command twice for it to run?

#55

You could rename INIT to INIT.ALL to make it more explicit.

Also would INIT.PN instead of INIT.P better in better keeping with the other pattern OPs? You could keep INIT.P but make it work in the same way as other P.* OPs (i.e. use the PN value).

1 Like
#56

I flashed Alpha 10 last night and indeed the innocent looking INIT wiped out the entire scene with no warning. Also, strangely it had the side effect of flipping the PARAM scaling into the negative range, 0 on all the way CCW and -16384 on all the way CW.

#57

The destructiveness is especially scary because my
intuition was that ‘init’ would run the ‘I’ script, initializing the scene.

1 Like
#58

should’ve read the description more carefully… i imagined INIT just initializing the teletype state. i don’t think clearing scripts should be a part of that (and it probably deserves a keyboard shortcut rather than an op, i can’t imagine a scene which would actually use it. a self destructing scene? :).

the purpose that i see for the op is initializing the teletype state to what it is when you just turn it on. imagine a scene that relies on A having the default value of 1. if i don’t change this value i don’t have to explicitly set it in the I script. the problem is if i switch to a different scene that does change the value, then i either have to remember to change it back manually, or it must be initialized in I.

so to me executing INIT would be similar to loading a scene on a teletype that was just turned on. using the example above, after i switch to my first scene all i have to do is execute INIT and it should work as expected. as a matter of fact, i would probably even put INIT as the first op in my I script.

i would also exclude clearing patterns as patterns are expected to be persisted between saves and scene switching. still would be handy to have a dedicated op to clear patterns…

#59

i’m going to kindly disagree.

typing INIT and pushing enter is not the same as a mistaken hotkey. if you accidentally type INIT, you’ll probably only do it once.

but @sam’s suggestion for INIT.ALL is a good one, to add more typing to convey intention.

#60

We could also make the syntax: INIT REALLY or INIT SURE. That would guard it pretty well, forcing users to read the docs.

I’ll look in to this, thanks!

@cmcavoy or @tehn, could you move the last few posts re: INIT to the init thread? Thanks!