#7

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.

1 Like
#8

I think CLEAR makes sense too.

2 Likes
#9

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?

3 Likes
#10

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
2 Likes
#11

we could also follow the ansible format where 0 means all

2 Likes
#12

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

1 Like
#13

Sure, it could.

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.

2 Likes
#14

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

#15

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

#16

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.

#17

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?

1 Like
#18

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

1 Like
#19

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.

#20

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.

#21

Yay, found what I was looking for in the code:

INIT.TR.ALL will clear all triggers

4 Likes
#22

Re: INIT.P x

I only know of Patter 0 - 3 and yet I can execute INIT.P 5 and not get an error. Are there other patterns possible beyond the four?

#23

Teletype does not produce an error for an out-of-bounds parameter (yet). Try:

CV 1000 V 5

No error.

So, no, there are no patterns beyond 3. If we want to know what actually happens in out-of-bounds circumstances, we have to look at the code.

static void op_INIT_P_get(const void *NOTUSED(data), scene_state_t *ss,
                          exec_state_t *NOTUSED(es), command_state_t *cs) {
    int16_t v = cs_pop(cs);
    if (v >= 0 && v < 4) ss_pattern_init(ss, v);
}

Here we can see that nothing happens when the parameter is out-of-bounds.

2 Likes
#24

I understand INIT.P to clear Pattern Data, so what is INIT.DATA clearing and in the code where the line reads

static void op_INIT_DATA_get

Does that “_get” necessarily imply there is a variable value following the op, such as INIT.DATA x

#25

The _get portion is an implementation custom and does not define that there is an argument. If you want to know how many arguments an operator takes, you have to look for instances of:

cs_pop(cs)

This is how an operator acquires an argument. INIT.DATA does not call this, so it has no argument!

#26

So what does INIT.DATA clear?