#1

So I have a pretty full Scene going, using Grid ops and what not and some ER-301 triggering.

I’ve been working on it for days, and now the Teletype is unresponsive. Starts up and I get the normal Live screen, but it doesn’t accept any keyboard or grid input. It’s frozen.

Any advice on how to revive it? Short of reinstalling system. I have a record of a previous version of this Scene, but it’s pretty elaborate. EEEEK.

#2

do you have any i2c ops? also, can you try unplugging and replugging keyboard/grid after tt is powered up?

edit: ah you did say er-301. that’s very likely the reason, it freezes tt if you have any i2c commands executed while er-301 is booting up. what you can do now is disconnect i2c from er-301, boot up, save the scene and switch to a different scene. then reconnect i2c and just remember to switch to an empty scene before you power down.

#3

Yea, I’m using both Telex modules, Ansible in Teletype mode, and tr/cv to a ER301. :grimacing:

Tried plugging unplugging…

#4

see above. the proper fix will be in the next beta but for now you have to use the workaround i’m afraid.

#5

I suspect I have a loop of sorts happening. Was in the process of making a grid fader set the PN.L, yet the Fader was previously getting it’s V from the PN.L…hadn’t changed that line yet.

#6

I will try this next.

#7

It was the 301…thanks for your help, as always, Monsieur Darkly.

2 Likes
#8

glad it worked! just remember to switch to an empty scene before you turn it off, and if it happens again just repeat the steps above.

2 Likes
#9

Are you running firmware v0.3.21 on your ER-301, Brian was hoping he’d fixed the problem on his side? But from what I’m gleaning from @scanner_darkly the issue might be fixed from the Teletype side in the next beta, is that correct?

#10

brian made some changes, unfortunately it’s not possible to completely fix the issue on the er-301 side, so yeah it’ll have to be a tt fix. more info here: Teletype 3.0

1 Like
#11

Actually, it appears that I do have some sort of strange loop happening in this script that is causing the crash. But it is complicated by the ER301, because if it crashes and the ER301 is attached I have to detach to get it restarted.

If it crashes when the 301 is NOT attached (which it is doing), a simple restart brings it back.

EDIT: Actually, it wasn’t a loop. I had a line saying If G.BTN.V 3: T PN.NEXT 0
Followed by Else: T PN.PREV 0

It was as if the PN.NEXT command was stuck and returning crazy voltages. I deleted the line and just used a straight PN.NEXT, and it worked fine. I rewrote the line as I originally had it and now it works. Weird eh? I’ve had it running for a few minutes now without a crash. Strange.

FURTHER UPDATE: So I was calling PN.I 0, watching it in real-time, and it was returning the raw data…like 13,473 or -4398, not the single digit index numbers like I was getting from the other Patterns. I don’t know what I did, but I tried accessing the value another way, and suddenly PN.I 0 started giving me the expected values, 1-7 or what have you. Could this be the glitch that was causing PN.NEXT to be so confused?

1 Like
#12

it’s hard to say what’s going on without seeing the full scene - can you post it here or PM it to me?

i doubt that pattern commands by themselves would cause a crash, unless you use the value returned as a loop boundary or something like that.

how do you set pattern length?

#13

Pattern length is getting set from a fader, like PN.L 0 G.FDR.V 3. For what it’s worth, it hasn’t crashed since I appeared get the PN.L to start reading the index properly.

#14

hmm it’s possible there might be some weirdness if length is set to 0

#15

I wondered…one of the things I did was set the fader range from 1 to 16.

#16

yeah i was going to suggest doing that as the default fader min is 0