#1

Running Teletype A235649, just updated.

The scene below sets up a paged interface that ends up acting somewhat like a 4 track, 8 step White Whale seasoned with a bit of Kria to use with my Grid64. It’s a work in progress, but I’m having some issues with reliability.

Triggers fired by the last line of script 4 are randomly not happening, no matter how many steps are enabled by the bottom row of buttons.

How to repeat: load the scene and send a pulse train to Teletype input #4 only. I have run it at 120-480bpm with the same results. Choose top left (Track 1) and then second row leftmost (pattern 1). You should see the third row start moving to indicate the current step. The bottom row enables step triggers. The faders in rows 5-7 are for CV. Pattern 0 elements 0 and 1 set the first and last steps of pattern 1 (0-6 as presented here).

I have a couple of Telex outputs, so you may have to change the last line of Script 4 from “TO.CV.N 2 …” to something suitable. I am experiencing NO dropped CV steps as far as I can tell, just the trigger outputs.

Edit: it makes no difference whether I have the grid plugged in or not, nor does having the keyboard plugged in change anything.

I’m grateful for any and all help. :slight_smile:

#1
G.BTN.SW G.BTNI; G.GRP.SW 0
X + 1 * 4 - G.BTNI 248
L X + X 3: G.GRP.EN I 1
L 56 63: G.GRP.EN I 0
G.GRP.EN + X 56 1

#2
IF EZ G.BTNV: BREAK
G.BTN.SW G.BTNI
X - G.BTNI * 8 - G.GRPI 1
L 56 63: G.GRP.EN I 0
G.GRP.EN + X 56 1
PN 0 + 2 * 4 / - G.GRPI 1 4 X

#3
IF EZ G.BTNV: BREAK
Y G.GRPI; G.GBTN.L Y 0 0
IF EQ Y 2: A - G.BTNI 8
IF EQ Y 7: B - G.BTNI 40
IF EQ Y 12: C - G.BTNI 72
IF EQ Y 17: D - G.BTNI 104

#4
A WRAP + A 1 PN 0 0 PN 0 1
G.BTN.SW + A 8 15
Y + A * 8 PN 0 2
IF EZ G.BTN.V + 183 Y: BREAK
Z + 0 G.FDR.N Y
TO.CV.N 2 Z; TR.P 1

#5
SKIP PN 0 7: BREAK
B WRAP + B 1 PN 0 4 PN 0 5
G.BTN.SW + B 40 15
Y + B * 8 PN 0 6
IF EZ G.BTN.V + 183 Y: BREAK
CV 2 N G.FDR.N Y; TO.TR.P 6

#6

#7
X * I 8; Y + I 56
G.GFX Y X 0 4 1 3 7 8 0 8 1
X + 183 * I 8
G.GBX Y X 0 7 1 1 1 0 0 8 1

#8
X + 1 * I 4; Y * I 32
G.GBX X Y 0 1 1 1 0 0 2 8 1
X + 2 * I 4; Y + 8 * I 32
G.GBX X Y 0 2 1 1 0 0 3 8 1
X + 3 * I 4; Y + 16 * I 32
G.GBX X Y 0 3 1 1 0 0 3 8 1

#M

#I
G.RST
G.GBX 0 248 0 0 1 1 1 0 1 8 1
L 0 3: $ 8
L 0 7: $ 7
G.BTN.PR 248 1

#P
2 0 0 0
1 1 1 1
0 0 0 0
63 63 63 63

0 0 0 0
6 0 0 0
0 0 0 0
1 0 0 0
0 0 0 0
7 0 0 0
0 0 0 0
1 0 0 0
0 0 0 0
0 0 0 0
2 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
-200 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0

#G
0000000000001000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000111111011
0111000000000000
0000000000000000
0000000000000000
0000000010000000

0 0 3 6 0 5 0 0 0 0 2 0 3 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

> teletype: grid # code exchange
#2

just in case it’s this: is TR.TIME 1 set shorter than the time between pulses?

#3

Thanks for asking! I experimented with values from 1 to 20ms, and I also checked to make sure it’s not an artifact of too long of an envelope time on the receiving end (Mutable Streams) preventing retriggering or the like. I can see the missed pulses on the Teletype’s LED.

#4

I wonder if somehow your EZ is being falsely triggered… I notice you use Y a lot in the different scripts. I haven’t done enough Grid Ops to follow the whole thing, but maybe Y is being overwritten by other scripts as script 4 is trying to do its thing?

#5

In my test case I am only feeding a pulse train to Teletype input 4 and not doing anything with the grid.

This is the test for the bottom row of buttons, which is the on/off row for triggers:

IF EZ G.BTN.V + 183 Y: BREAK

I wrote this on an older version of firmware that didn’t have J and K local variables, but I have treated Y and Z as temp vars in all cases. In the current “script 4 only” test it shouldn’t be a factor, but I’ve learned to not rule anything out too soon. :slight_smile:

#6

I should add that I am monitoring the variables and seeing correct step counts for A and Y.

Now doing some more testing, and I may not in fact have tried 20ms as this length seems reliable. 10ms drops triggers, and since it’s the dark predawn hours I can see that the trigger output LED gets dimmer here and there.

I’ll re-install my O’Tool+ and see what the output pulses look like. Hang on …

1 Like
#7

OK, I think I found the issue: it appears the trigger’s ON time is shrinking by about 10ms or so in a recurring pattern.

This video was taken with TR.TIME set to 10. The pulse train is 480bpm:

#8

For final confirmation that the issue isn’t related to logic errors in the script(s), I switched to a TXo trigger output. There is no observable jitter for any value of TO.TR.TIME down to 1ms, and no dropped triggers for any other reason.

#9

I’ve been getting dropped pulses when scrolling through the pattern screen… Even with the simplest possible metro script:

CV 1 N P.NEXT
TR.P 1

But I’m guessing my metro rate (fast) is barely longer than the default pulse duration.

#10

i thought i saw something similar recently. will take a look!

1 Like
#11

i’m not able to reproduce this with a simple script. also looking at the code the part of the code that handles trigger pulses hasn’t changed since 2.0.

@jnoble could you try removing remote ops one by one and see if that fixes the issue? or if you could create a simpler scene that replicates the issue that’d be hugely helpful!

1 Like