Teletype 2.0 beta (release candidate 2 released 13th July 2017)

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

1 Like

Quoting myself…

Anyone wish to comment?

This is one of the last things to resolve…

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

1 Like

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.

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

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

2 Likes

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

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

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

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.

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?

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

1 Like

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

1 Like

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));
}

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

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

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!

You need to rule out Ansible as the root cause, in my experience it locks under high load and takes out the i2c bus. If you’ve got the reset switches installed in your modules this is fairly easy to test. Reset just the Teletype and then try to trigger a pulse on Ansible (TR.P 5), if that crashes immediately then it’s Ansible at fault (or possibly another module on the i2c bus).

Whoops I don’t think I meant to commit that…or maybe I did… that day was a bit too hectic.

at some point i removed ansible remote commands from metro, and i could still get it to freeze with telex remotes only. also it looked like it worked with fewer i2c commands but adding more caused it to crash - i only tested this scenario once though, so might not be entirely true.

Is that with a local build, or with the prebuilt hex?

If it’s a local build, make sure that libavr32 is at the correct checkout (git submodule update).

If you’re still getting issues, could you also try with the latest version from my 2.0 branch?

the prebuilt d059926 hex. i’ll try the latest (and yep, will make sure i have the right libavr32 version), just need to finish setting up the toolchain.

i thought i2c issues were related to also masking UI_IRQ_PRIORITY but that’s not the version d059926 build uses. but i have a feeling i2c could be related to the fact both i2c and trigger interrupts are level 3.