yep, what @chapelierfou said is correct, i’ve added grid support to teletype firmware, and then the scene was all done with teletype scripts using some of the new grid ops. i’ll post it later today with some explanations!

Reading through the code, I began to wonder if it’d be possible to make the operators that take a large amount of number parameters slightly easier to read. The only way I can think to do that at the moment is to perhaps introduce a syntax for pairs: G.BTX 1 1,1 2,2 1 5 1 4,1 (for reference G.BTX id x y w h latch level script columns rows).

yeah, those ops are heavy… this is actually a simpler version, i went though several revisions trying to balance flexibility with compactness (as an example, i’d love to be able to specify the brightness level for pressed buttons, but that didn’t make the cut, right now it’ll use the max brightness).

what you suggest would improve readability but would have major implications for the language, so likely not possible unfortunately.

other option i considered was to have an op to set some defaults, and then have a shorter version for button creation. i tried that and discovered it was really nice to be able to create a group of buttons with just one line instead of two, that’s why i went with this op at the end.

a really cool (and i think elegant) solution would be to have a hint displayed on a separate line that would show the name of the parameter you currently on - this is a major redesign though…

a really cool (and i think elegant) solution would be to have a hint displayed on a separate line that would show the name of the parameter you currently on - this is a major redesign though…

The Teletype language is growing to a point where this type of code hinting would be so incredibly helpful, especially if you’re like me, and don’t eat/sleep/breathe Teletype every day (and kinda start to forget stuff when I step away for a while).

Totally understand this would be a major undertaking, and maybe shouldn’t be highest priority, but any usability help such as this will be immensely appreciated.

good news - the usb cable worked, and i think i fixed it. the issue was due to refactoring some of the G.LED code which i did not test after - pretty embarrassing! there might still be gremlins, so please keep an eye on anything that looks suspicious, but i did test it with the pong scene (the latest video posted above).

I have noticed that pressing any two of the cells simultaneously triggers the script, but fails to change the state of the leds. To clarify, if the leds are lit they remain lit, similarly if they are dimmed they remain dim.

By the way, this update is incredible! Thanks @scanner_darkly for putting in the work!

Edit: After checking a few more button sizes I realized that this happens with any latching button larger than 1 cell.

edit: this got me thinking, perhaps this could be a feature where on bigger buttons you could also have a separate property indicating the overall number of buttons pressed (this probably makes more sense for momentary buttons though).

yeah, basically you can’t plug a grid directly into teletype, it won’t work (and possibly not a good thing to do to teletype). what you need is some option to power grid externally, ext5v / monome switch / offworld board / Y usb cable adapter.

3D printer came in. Ended up throwing a bunch of time at modeling to fix all the broken stuff in the house. Made an extended tank for my vape, fixed the vegetable steamer, built reinforcement brackets for weak IKEA furniture…

And the firmware is on github. Time to make it an oscillator, I guess. Not even joking, I will actually be making it an oscillator to sweep for physical resonance so that I can identify noises and solve them either by tightening things, adding foam tape, or possibly printing inertial dampers.

To keep it on-topic, I will push out 2.1.0-beta6 after the weekend. I want to expand the testing suite to include more of the new behaviours of L/I, SCRIPT, and possibly DEL and other timed code, but I’d have to expand the simulator to do that. I’ve got a couple of 8 hour builds queued up, so I should have the time to tackle all of this by Monday.

Edit: my bad, no i2c on-board. I’ll still set up a foley mic and use it as a sample source, however!