#143

not sure about this one… feels like it will be cumbersome. the reason i say this is because it reminds me of the way to input strings with hardware that doesn’t have a dedicated keyboard, say like naming projects on elektron gear (doing a search on my bluray player is also similar and i find i avoid using it for this very reason). grid will be worse as you’re dealing with 128 buttons vs something like 30.

the 2nd reason is that this mode is not really intended as a replacement for grid input, but rather as a way to test grid scenes. in this case you probably won’t need to test pressing specific coordinates as much as specific controls (say, you want to test that pressing button 5 does what it’s supposed to do).

another purpose is using grid scenes without a grid by programming triggers or metro script to imitate button presses, in which case a dedicated op will allow you to do this with very little scene modification. for this purpose an op for coordinates also makes sense as you could set coordinates based on IN or PARAM or TURTLE or even sequence them with pattern data.

3 Likes
#144

For debugging purposes only:

  1. Hot key for grid input mode
  2. Arrow keys move cursor from button to button in simulated grid
  3. Spacebar simulates button press

Is that more or less cumbersome than what you imagined?

Will there be a way to see the bottom 8 rows of a 256?

2 Likes
#145

that’s how it would likely work and yeah, that to me sounds cumbersome, but it might be a personal preference.

absolutely, there will be a way to switch between viewing upper and lower half for 256.

1 Like
#146

Occurs to me that I can just use OPs in live mode for debugging without cluttering scripts, so I can live without this grid input simulation mode. It’s just how I imagined it working at first blush.

2 Likes
#147

yes - was going to address that point specifically and forgot, thanks for mentioning it again!

the idea is to use live mode first to build the UI (create a control with an op, confirm visually, copy the line to init script), then test scripts by imitating pressing controls. of course you could do the latter simply by executing scripts with F1-F8, but for those scripts that rely on the id or the state of the last pressed control you’d want to be able to test that as well, and imitating a control press will let you do that.

3 Likes
#148

While I share the pain I think this is a different situation as we are not searching for values that are positioned on a grid in an more or less arbitrary, at least uncommon order.

I like the idea of programming grid presses from triggers with an OP but also find it intuitive to move the finger over the virtual grid using the arrow keys and then press with a keystroke. A combination with cmd or alt might be useful to not clutter the command line, though.

To me the cumbersome equivalent to your blueray player would be counting dots on the tiny tt screen and then having to manually insert them into operator parameters that work with coordinates.

So how about both ways: an OP for programming and arrow keys for easy manual access?

1 Like
#149

i’ll consider it but won’t promise at this point. i still think using it to test presses is really awkward but i think this might be a good way to see coordinates, and going even further a way to map areas and have a shortcut that would put the coordinates, width and height into the live input line so then you could easily turn it into a grid op.

everything has to be balanced against elegance of the user interface though and this does feel a bit hackish to me.

3 Likes
#150

@mlogger i’ve updated the pong scene to run on the latest firmware: pong.txt (1015 Bytes)
sorry for the delay!

1 Like
#151

started looking into the issue @jasonw22 experienced. i’m not able to reproduce it by using grid with teletype normally, but i managed to “lock” the grid by quickly switching between A/B on monome switch which is what i’m using to power the grid. i’m able to reproduce it reliably each time but i do have to switch very quickly back and forth to get it to lock.

@tehn - this to me indicates that the handshake getting interrupted in this manner means something gets corrupted perhaps? going to play with it some more and debug, particularly check what’s happening with ftdi_setup.

2 Likes
#152

brilliant! thanks very much :slight_smile:

1 Like
#153

check what’s happening with ftdi_setup.

ok, that’s the crufty old aleph layer.

i had a poke through it; there’s definitely a potential problem if device goes away during the request for device/manufacturer strings. ( uhi_ftdi:ftdi_get_strings().) that function should return an error if any of the send_ctl_request calls fail. (instead of just returning early!) ftdi_setup should check for those errors, instead of just continuing with device setup using whatever string contents are in uhi_ftdi static memory… or worse yet, unitialized char pointers in ftdi_setup.

sorry!

4 Likes
#154

thank you, this is really helpful! i’ll try the changes you suggested.

1 Like
#155

gave it a try and didn’t seem to help. i can still lock it by quickly switching back and forth once. now, the interesting part is that only button press stops working, but updating LEDs seems fine. i’ll keep digging! really should get it hooked up to debugger at this point…

#156

yeah i haven’t had any trouble with those routines on aleph. the worst thing that happens is either a device gets registered which never produces any data (because there were old strings passed to protocol detection) or no device is registered (because protocol detection gets garbage strings and gives up.) still, it’s ugly and incorrect as is.

then again i’ve never tried rapidly switching the usb connection on and off :slight_smile:

1 Like
#157

What’s weird too is that I wouldn’t describe anything I’ve done as “rapidly switching the usb connection on and off”. Just, you know, unplug the keyboard, and plug in the grid, or vice versa 4 or 5 times in a row, at a “normal” pace, as you would do when trying out the grid ops for the first time. But it sounds like @scanner_darkly can’t reproduce it in that manner.

It’s really intermittent. Maybe if I throw some salt over my shoulder it won’t happen again.

1 Like
#158

well this is embarrassing :slight_smile: i think i found the bug, at least for my scenario with fast usb switching. this was due to me fixing the bug reported by @Justmat earlier in the thread, where if you define a latching teletype button that consists of more than one grid button then pressing on one grid button would latch it, but if you press, hold and press another button it would release it.

in order to fix that i started tracking number of presses and releases on each teletype button, so pressing additional grid buttons within the same teletype button would produce no action. but if this count is off then the teletype button will stop responding (as it thinks it’s still being pressed). somehow fast usb switching gets it in this state (which is weird in itself…). i reverted this change and now i can’t get it to lock! this is even if i revert the fix for ftid_setup.

@jasonw22 i’m really curious now if you can try and reproduce it again, but this time add another non latching button, so something like:

G.BTN 1 0 0 4 4 1 4 0 
G.BTN 2 5 0 4 4 0 4 0

and then see if the non latching button still works. if this is the case then it’s the same cause (i hope!). not sure about the fix yet, i might just revert to the previous behaviour - i think multiple presses on the same button is not really a big deal. will sleep on this.

2 Likes
#159

Different behavior this time. Both buttons work, but G.CLR does nothing. Both buttons persist.

Power cycled and tried again, same behavior.

#160

do you mean both buttons latch?

for G.CLR could you describe the behaviour a bit more - so you set some LEDs on and you can see that on the grid but executing G.CLR does not clear them?

#161

No, the first button latches, the second doesn’t.

Then, after running those two G.BTN commands, I run G.CLR and the buttons keep existing and responding to presses.

#162

G.CLR will only remove LEDs set with G.LED and G.REC, to clear both controls and LEDs you want G.RST

try this:

I:
G.BTN 1 0 0 4 4 0 4 1 
G.BTN 2 5 0 4 4 0 4 2

1:
G.LED RAND 15 RAND 8 RAND 15

2:
G.CLR

now button 1 will set random LEDs and button 2 will clear them.