Yes, that should work. I am using a Y splitter from a Beatstep Pro, with a micro/mini adapter.
This is really great! Do you think that something like this, i.e. a turtle visualizer, would be less script hungry once the turtle is implemented on the TT?
What about a powered USB hub… have the keyboard and grid plugged in at once?! Or is that too crazy?
yeah, definitely, as you wouldn’t need to implement turtle logic in the scripts, just the visualizing part and the controller part (controlling turtle actions with grid).
unfortunately this is not possible… hubs have their own protocol which is not supported right now, and adding support for it would be a major and non trivial task.
i have to look after my partner for a few more days, so unfortunately i won’t be able to post a working beta until next week. if any of the devs who have the toolchain set up would get a chance to build from my branch (i have a suspicion the issue is due to how my toolchain is set up on my laptop which i have here) that would be awesome - please PM me!
a different take on the previous scene - now it will generate a note (which is determined by the horizontal position) whenever it hits a block. it will also change the direction randomly. this one actually turned out to be easier than the previous one, everything took 22 lines of scripts which leaves quite a bit for further exploration.
Wow that’s beautiful – a great way to mix randomized events in a way that still sounds natural and familiar.
Very excited for this!
unreal that you accomplished this with 22 lines. super super impressed.
A TT noob question: do you do all the coding inside the TT?!
He’s coded all the Grid TT operators. Then, what you see there is made with TT only, i believe. Hopefully this will be soon part of the original TT !
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!
Amazing work, I’m keen on trying this out.
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…
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).
the new beta (also posted in the op): teletype.hex sep 20 [828ef11]
the pong scene: tt00.txt
i made some additional changes, so it’s 25 lines, not 22 -
CV 3&4 will be also set based on direction, and the knob controls speed.
i’ll post a line by line explanation of the scene tomorrow!
Only just started playing with the latest grid/tt beta, but I have noticed a strange behavior.
If I try to put
in a script, pressing enter to place the line in the script causes the contents of the line itself to change to
At first I thought I was just crazy, but it happens across all script numbers.
A typo by the looks of it.
@scanner_darkly if you get the tests running, there are some that check for misnamed OPs.
(They also check that you’ve set the number of
params correctly, but you’ll need to make sure that
STACK_SIZE is at least 2 bigger than the largest number of
When working with a 2x2 latching button:
G.BTN 3 1 6 2 2 1 4 2
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.
both should be easy fixes, i’ll make a new beta tonight. thanks for testing it, so awesome to see it in the wild!
@sam - thanks for checking! yeah i need to get tests going soon. re:
STACK_SIZE - already changed it to 10 in my branch.
You need to make sure it’s 2 bigger than the biggest OP you have to run the tests (so at least 12, just go for 16). Otherwise you’ll get a stack overflow when you run the test suite.