Yes, it’s just that there are several moderators and it’s not easy to call their attention to these things.
I got a message that it was removed to the other thread. It just was referring to the icons in this thread too but not very clear and now seems a bit displaced over there.
I am not sure if we have to discuss moving posts around and deleting threads again but it does feel more strange to me this way. I think I’d like starting a new thread and referring to it more - everyone can follow what’s happening then and might repost things over there. In my case it would not have been worth posting it again. I had not seen the new thread intime and discussion has already gone further there…
Trying to get living/flowing things like discussions in order by replacing parts of it from a superior point does not always work very good I think…
Sounds like we need a meta post on the matter.
My 2 cents is that yes, it causes some confusion for the authors of the moved posts, but it does so for the benefit of the readers. Do the needs of the many outweigh the needs of the few?
Live long and prosper, grid integration thread.
honestly right aligned looks pretty great. but perhaps it’s easiest to just hide it altogether when in grid mode and make a bigger grid.
@cmcavoy recently took on trying to sort development issues, which this is one of them. he moved the post, i don’t believe it was deleted. i will make a new post about this.
Any idea what might be going on here?
G.BTN working very intermittently, then not working at all, then
G.CLR stops working too.
can you let me know which version are you using? how is the grid powered? and if you could send me the script i’ll see if i can reproduce it. also does it just start happening at some point or is it usually preceded by some other action, like replugging the grid?
2.1.0: B0F9779 grid
Just doing the grid studies on https://github.com/scanner-darkly/teletype/wiki/BUTTONS
G.BTN 1 0 0 2 2 1 5 0 entered in live mode. Then I switched it to
G.BTN 1 4 4 2 2 1 5 0 just to make sure I didn’t have some dead buttons.
I had just done the Basic Visualizations study, with all the swapping between keyboard and grid that entails.
thanks for the info! will take a look (it will have to wait till tuesday as i’m traveling right now). do you have another grid? if you do could you try it as well?
Yes, I will try it today.
forgot to ask, when that happened have you tried disconnecting / reconnecting the grid?
Yes, no change in behavior when I do that.
Weird. I can’t reproduce it today. G.BTN appears to be working fine on both grids.
thanks for checking!
i experienced something similar at one point and couldn’t reproduce it later. and then later i fixed a bug that would also result in a similar behaviour but only when using
G.REC. so really not sure what’s going on there.
i have a suspicion this might be related to the grid/hardware handshake - @tehn i seem to recall there were some changes made in that area, could it be related? anything i could try? would frequently reconnecting the grid somehow mess with it?
Just had the same behavior return (both 256 and 128 grids behaved the same). Power cycled. Everything works. Gonna make my way through the rest of the studies and just power cycle if it happens again. Try to notice if there are any other precursors to the condition.
i haven’t seen any issue with frequent reconnects, though i guess it’s always worth testing on another module with libavr32 (ie ansible)
@jasonw22 can you redescribe the issue? dead buttons? for both grids? the 128 is newest edition?
no, not dead buttons. newest 128 grid and 2012 256.
intermittent G.BTN (that gets gradually more intermittent until no response at all).
power cycling completely clears it up.
when i reproduced it just now, it went from working to not working almost instantly. the first time it happened, it happened much more gradually
@scanner_darkly do you want to make 100% sure that your
libavr32 check out is on the correct commit. I have a recollection of similar disconnect issues in the past.
when i rebased from the master i made sure it was referencing the same version. entirely possible the issue exists there as well, and grid/teletype case surfaces it more due to how it’s used. as @tehn mentioned worth testing with ansible.
the fact that it’s intermittent is worrisome, i certainly hope it’s not related to the interrupt issues we experienced before. i’ll do more digging.
What if you could use the arrow keys and space bar to select and ‘tap’ a button on the virtual grid? I think it might be more intuitive to stick to the more visual format than to use an OP and XY coordinates
I can think of situations when you might want to script button presses, as a conscious and permanent part of your script, which seems to justify an OP, but for debugging, I agree with @xeric that it’d be nice to have a way to test input without cluttering scripts with debug code.