#267

I managed to isolate the problem:

1 (externally triggered)
SCRIPT 2
SCRIPT 4

2
L 0 5: SCRIPT 3

3
(empty)

4
TR.PULSE 1 (this one is just for visual feedback)

Issue : SCRIPT 4 isn’t triggered.

So i think that LOOP is breaking the chain of action preventing to get back to SCRIPT 1 in order to finish its code (here triggering SCRIPT 4).

@sam Hope this helps.

1 Like
#268

If you change

L 0 5: SCRIPT 3

to:

L 0 4: SCRIPT 3

does script 4 trigger?

edit: checked it myself, and it does work. Basically, you’re running up against the new script loop protection. I can probably make some tweaks to how it works inside a loop… will write up the options tomorrow.

#270

Yep you are right it works with that patch but in the complete one it won’t work until i decrease it to L 0 2 (a lot of thing is going on in that patch, with a lot of SCRIPT triggering, i can’t tell if it is related).

BTW i also tried to replace the LOOP with something like that and reached hit the same wall:

2
SCRIPT 3
SCRIPT 3
SCRIPT 3
SCRIPT 3
SCRIPT 3
SCRIPT 3

It would be awesome if the number of values could be increased to something like 8 or 9 or at least 6 as the number of lines in a script :innocent:

#271

Such a simple change…

Basically the new script loop detection works, not by trying to detect loops (if you try to do that you run into the halting problem), but instead by limiting how many times any script can run from a single trigger (or metro, or delayed command, etc). The reason for doing this is to stop the infinite loop. But because scripts can recurse into each other there is a danger of a stack overflow, thus the limit of only 8ish SCRIPT calls.

(as aside it is possible to remove the danger of the stack overflow by using a ‘trampoline function’, but that would require far more work)

Anyway when I wrote that code I was focusing purely on the danger of the stack overflow which comes about from nesting scripts (e.g. script 1 calls script 2, script 2 calls script 3, etc). But the way the code works is overly simplistic and all it does in effect is count how many times you run any script. So the solution is to decrease the number after the script finishes. That way the limit is on how deep the nesting is, not how many you run.

tl;dr: you can use SCRIPT a lot now, the limit is how deep the nesting goes, not how many scripts you run.

The code will be in the next beta, which may in fact be the first release candidate.

4 Likes
#272

Thank you very much for that readjustment (and the hard work btw).

1 Like
#273

Quoting myself…

Anyone wish to comment?

This is one of the last things to resolve…

#274

how about changing the ansible meadowphysics to ME.PRE etc?

1 Like
#275

Could do. Given that it’s going to be a breaking change…

Would you want to go with the long versions of the names…?

  • ME.PRESET
  • ME.RESET
  • ME.OFFSET

We could add aliases in for those concerned with space.

#276

My 2c, is that AMP is more memorable that ME. It would be nice to bring the two sets of command groups to a common point at some point in the future.

1 Like
#277

New thread started for those that wish to contribute to the documentation efforts…

2 Likes
#278

honestly the shortening was originally due to name collisions with the standalone mp module. i followed over these shortenings to the KR and LV and CY commands.

i feel it’d make sense to have uniformity. i don’t have a particular preference myself. the short versions aren’t too obtuse, but full length is more readable.

also i like shorter (less dense) line commands, so the full-length words to me don’t threaten usability

re: AMP, i don’t like this because amplitude is such a prevalent parameter in modular that it seems confusing.

@sam ansible with new libavr32 running fine so far…

1 Like
#279

Ha. I didn’t even see that. Definitely an important point.

You can see all the Ansible op names in one place here:

#280

running newest TT + ansible, lots of i2c in the metro at 10ms and all is well.

would be happy to check any specific known issues.

#281

Finally taking this for a spin. SO much to like (subcommands in particular :thumbsup:).

A quick question: I’m seeing some issues using hotkeys to trigger scripts. Is anyone else seeing this?

#282

Are you talking about using the function keys? Or the older hot keys (I don’t think they work anymore).

1 Like
#283

Ugh. Sorry, yes. Old hot-keys. Function keys work great. Thanks!

1 Like
#284

Question… are the AND, OR and XOR ops supposed to be bitwise or logical. The docs say logical, but the code is bitwise:

static void op_AND_get(const void *NOTUSED(data), scene_state_t *NOTUSED(ss),
                       exec_state_t *NOTUSED(es), command_state_t *cs) {
    cs_push(cs, cs_pop(cs) & cs_pop(cs));
}

static void op_OR_get(const void *NOTUSED(data), scene_state_t *NOTUSED(ss),
                      exec_state_t *NOTUSED(es), command_state_t *cs) {
    cs_push(cs, cs_pop(cs) | cs_pop(cs));
}

static void op_XOR_get(const void *NOTUSED(data), scene_state_t *NOTUSED(ss),
                       exec_state_t *NOTUSED(es), command_state_t *cs) {
    cs_push(cs, cs_pop(cs) ^ cs_pop(cs));
}
#285

i suspect that logical is more often useful in TT (ie, for conditionals)

not sure how we’d differentiate having both, short of the symbols

#286

Agree. Symbolic isn’t that great anyway in my experience. It’s far too easy to type the wrong one by accident!

#287

did some exploratory testing with d059926 build yesterday, tt with iiBackpack, just friends | ansible | 2x TXi | 4x TXo on i2c bus, ansible on your latest firmware as well. was able to get it to freeze easily with a bunch of i2c related commands in 10ms metro script.

this was just from quick testing, so need to test more in a systematic manner, but it looks like doing any heavy i2c stuff in metro script is fine until i enable triggers, and when this happens they don’t even need to be audio rate.

i gotta say overall the UI seems fairly responsive even with audio rate triggers and a super quick metro script, so perhaps having keyboard/screen on their own priority is not really needed, but i’d like to play with some ideas.

@sam - i see that you since also changed timers_pause to mask UI_IRQ_PRIORITY - curious about this change… i’ve got some ideas i want to try as well once i set up the toolchain (one of them being - maybe use a mutex to make event code thread safe instead of disabling interrupts).

oh, and all the v2 changes are awesome!