(Teletype) State Clearing Operators

[sliderule]

@tehn suggested that the teletype could use an operator to clear state variables, such as:

• Variables
• Queue
• Stack
• Delays
• CVs
• Slews
• Script Mutes

Clearing these will simulate power-up conditions, and could be called RESET.

@sam noted objection to the use of RESET as it has meaning elsewhere in the teletype ecosystem.

Potential names for such an omnibus operator:

• RESET - 1 vote against, but @tehn’s initial suggestion
• REBOOT although it belies the true nature of the operation
• INIT although it also has meaning in teletype

---

@sam also suggested splitting the operations up, such as

• P.INIT / PN.INIT
• INIT.VARS
• S.INIT
• etc…

2 Decisions:

1. Omnibus or individual operators?
2. Operator name(s)

[sam]

Omnibus or individual operators?

We can have both… INIT.ALL in addition to INIT.VARS, etc.

I think some sort of initialisation OP is necessary. While I would like the granular choices, it’s not as important as the ‘omnibus’ version. So if it’s only me that wants them don’t bother.

I don’t like RESET as it has a specific meaning in Eurorack, and with sequencers in general. Best to save the name for that use (as it is already with WW.RESET, MP.RESET).

I also think using the name INIT only works with the granular approach, as INIT on it’s own sounds like it should run the INIT script.

I’m not a massive fan of the name of the KILL OP either. If we do end up with granular OPs I would like the name of that OP brought into the new naming scheme (with an alias for backwards compatibility).

[sliderule]

Exhaustive List of Teletype State

Never Loaded From Scene

These state parameters are never altered when loading a scene (bar init script activity), and are clear candidates for INIT operators.

• Variables
  • O
    • Inc
    • Min
    • Max
    • Wrap
  • Drunk
    • Min
    • Max
    • Wrap
  • Flip
  • Pattern Number
• Queue
• Stack
• Output CV
  • Value
  • CV Offset
  • Slew
• Output Triggers
  • Value
  • Polarity
  • Time
• Input CV Scale
• Param Scale
• Input Triggers Mute
• Metronome
  • Enable
  • Time
• Delays
• Turtle
  • Position
  • Speed
  • Direction
  • Fence
  • Bounce Mode
• Script Last Time
• Every Count
• Every Last

Scene-Related State

These states are set when loading a scene. Although they may never need to be called by a script, they would be handy for clearing out unused parts of a scene.

• Scripts
• Text
• Pattern Data

---

Design Discussion

Granularity of Operators

Each of the above non-scene state datum represents a potential departure from power-on conditions, and should be accessible for reset to the user. We can say that each of them already has the finest granularity of control, e.g.: A 1 or TR.TIME 20, but this presumes that the user understands the power-up state.

The operators under design seek to create groups of these items that represent a common operation, but what constitutes “common” is arguable. For example, do we allow users to reset the parameters of:

• individual trigger outputs, e.g: TR.INIT 1 or INIT.TR 1
• common parameters for all trigger outputs, e.g.: INIT.TR.TIME
• only omnibus access, e.g: TR.INIT or INIT.TR

Here we can see two separate axes of granularity. Each of them may be considered “useful” to one user or another, but which of them fit teletype the best?

Scope

• Is there anything on the first list that should be excluded for some reason?
• Do we want scene-clearing operators?
• Should we allow users to set values at granularities where they currently cannot?
  • E.g.: INIT.TR.TIME 125 to set all trigger times to 125.
    • This can be accomplished with L in the existing syntax, so maybe not.

Finest Granularity, Broadest Scope

Here’s an example set of the finest granularity of TR initialization operators using the INIT-with-suffix syntax. There are group-setting operators, and each grouping axis is represented.

INIT.TR                         | omnibus, clear all parameters of all triggers
INIT.TR 1                       | clear all parameters on trigger 1
INIT.TR.TIME                    | clear the time value of all triggers
INIT.TR.TIME 20                 | set the time value of all triggers to 20

Coarsest Granularity, Narrowest Scope

The most cut-down version is a single operator:

INIT                            | clear all state data

Scene-Related State

Same discussion to be had about granularity here, although I can’t see the use of grouping common parameters of the patterns together, e.g: INIT.P.I 5 (set all pattern indexes to 5), as this doesn’t seem useful. Also, these operators might get vetoed as they are scope creep above the original approval.

Finest Granularity, Broadest Scope

INIT.SCENE                      | load a blank scene
INIT.SCRIPT 1                   | clear script 1
INIT.SCRIPT                     | clear all scripts
INIT.P 2                        | clear pattern 2
INIT.P                          | clear all pattern data
INIT.TEXT                       | clear text (probably not useful) 

Operator Verbage

• Traditionally in teletype, these sort of operations end up as a suffix of the existing operator, e.g.: TR.INIT.
• It may be easier for users to understand to use INIT as the base operator, however.

---

I think that I have explored all there is to think about with these operators. Now I need @tehn’s scalpel to cut the cruft out.

Once I have an approved set of operators, I’ll roll them into 2.2 .

[laborcamp]

REINIT (re-initialize)
FLUSH
?

[jasonw22]

INIT implies setting initial values. FLUSH implies a zeroing, which seems more accurate.

[sliderule]

I like INIT, I think it’s a good idiom. You’re initializing values to the fresh-boot state.

REINIT (re-initialize)

Redundant if you’re not going to use the word INIT for any other operator.

Would CLEAR be a better word for the user? WIPE?

[scanner_darkly]

i like INIT. out of all suggestions it seems closest to the op purpose (as it’s not just clearing or resetting values, it’s really getting it into the same initial state as when turning the module on).

it’s also similar to concept of synth patches having INIT as the starting point. as @sam mentioned there might be some confusion with the Init script, but i think it’s actially an advantage - they are complimentary, one is scene independent and the other gets the initial state for a specific scene.

[laborcamp]

I think CLEAR makes sense too.

[tehn]

i’m going to agree with INIT as there are non-zero values at startup (ie trigger times, metro times)

---

having micro-granularity (ie, access to just TR, let along individual TR channels) is overkill

i think it’d be effective to separate the list of init’able values into groups.

ie: hardware (cv/tr/param/input), time (metro, delays, counts), data (everything else), pattern, scene

i don’t think we need to have value-setting, ie, for tr.time. that can be done easily with a loop. we want fast/compact broad-sweeping actions that don’t require detailed scripts.

i like:

init.scene
init.script x
init.script
init.p
init.p x

because those to me seem like productivity helpers.

init.cv
init.tr
init.data
init.time

maybe would be sufficient for the rest?

comments?

[sam]

INIT.SCRIPT 1                   | clear script 1
INIT.SCRIPT                     | clear all scripts
INIT.P 2                        | clear pattern 2
INIT.P                          | clear all pattern data

Does that actually work? Even if it does, I’m not sure I like the idea of using the get/set functionality to give OPs variable arity. No other OP works like that.

I’d be happier with:

INIT.SCRIPT 1                   | clear script 1
INIT.SCRIPT.ALL                 | clear all scripts
INIT.P 2                        | clear pattern 2
INIT.P.ALL                      | clear all pattern data

[tehn]

we could also follow the ansible format where 0 means all

[scanner_darkly]

i like this, but won’t work for patterns unfortunately…

[sliderule]

Does that actually work?

Sure, it could.

give OPs variable arity. No other OP works like that.

Well, there’s my new word for the day. I agree that this is a departure from TT syntax, and have no problem with .ALL.

[unity2k]

INIT.TR is not clearing all my triggers, I get the message “Not enough params.”

So I have to clear them individually with INIT.TR.1 etc

[dan_derks]

So I have to clear them individually with INIT.TR.1 etc

If I’m reading everything right, I think:
L 1 4: INIT.TR I
should do it in one fell swoop, but I have the grid beta on my TT

[unity2k]

I get that it should, but INIT.TR throws the message “Not enough params.”

Also tried: “L 1 4: INIT.TR” but it too gives the above message.

[laborcamp]

You need to specify which trigger you are addressing:
INIT.TR 1 (the “1” is your missing param)
same when you are making a Loop:
L 1 4: INIT.TR I (where the “I” is the variable that is changing while loop executes, so on first loop, I = 1, then I=2 etc.)
Does that make sense?

[dan_derks]

included line breaks in my post above to make the code a bit clearer

[unity2k]

It makes sense, but as I look above to Sliderule’s earlier post about the command I read this that it should be clearing all triggers.

INIT.TR | omnibus, clear all parameters of all triggers

[sliderule]

I can’t find the result of this discussion so I must have gone with my best assumptions as to which axes were most useful. I recall someone arguing that if you could do something with a loop, then the omnibus version was redundant. I know I was trying to keep operator count down in this feature.

TL;DR: broadest scope as described above does not necessarily represent current or final implementation.