#26

I think this is the case, or it is for me at least. The TT boots up fine, but the grid commands only seem to work on the top row of the grid. For instance, the command

G.BTN 1 1 1 2 2 1 5 0

gives me 2 led lit on the top row only. This is also true of

G.REC 3 3 4 4 0 RRAND 1 15

which lights the leds at 3-6 on the top row.

#27

interesting, i would expect it to either work or not work at all… a couple of questions - what grid are you using, 64, 128 or 256? also, could you try plugging in the grid, then plugging the keyboard again and repeat the same ops and see if that makes a difference? there was a bug where it would use the grid size to determine how to render, so it wouldn’t do it properly until grid was plugged in, but i fixed it a while ago and it shouldn’t matter anymore, but maybe it sneaked back in.

thanks for help with testing and detailed report!

#28

I am using a 128, the most recent one.

I tried:

  1. Connect Grid
  2. Disconnect Grid/Connect Keyboard
  3. Run “G.LED 8 8 15”
  4. Reconnect Grid

but the same behavior persists. ( in this instance, led 8 on the top row lit.)

#29

thanks for checking! let me see if i can find where the problem is (or try and find a cable here so i can reproduce). if that fails i should be able to post a confirmed working version on tuesday at the latest.

2 Likes
#30

inspired by the turtle discussion i wanted to try a simple idea, a dot bouncing in a rectangle. managed to do it but had to use almost all of the scripts - half of it is the actual logic and half of it is determining the speed and direction from button presses.

distance between the pressed buttons determines both speed and direction. whenever a wall is hit the corresponding trigger is fired. CV outputs are used for pitches which correspond to horizontal and vertical speed. i’ll post the actual script once i refactor it a bit (also, sorry for posting more examples without a working beta, i should be able to post a proper beta on wednesday!)

9 Likes
#31

I’m curious if one would be able to use the grid with teletype using the Y usb adaption detailed in this thread?

1 Like
#32

Yes, that should work. I am using a Y splitter from a Beatstep Pro, with a micro/mini adapter.

2 Likes
#33

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?

#34

What about a powered USB hub… have the keyboard and grid plugged in at once?! Or is that too crazy? :wink:

#35

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.

2 Likes
#36

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!

6 Likes
#37

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.

17 Likes
> teletype: grid # code exchange
#38

Wow that’s beautiful – a great way to mix randomized events in a way that still sounds natural and familiar.
Very excited for this!

#39

unreal that you accomplished this with 22 lines. super super impressed.

8 Likes
#40

Very impressie!
A TT noob question: do you do all the coding inside the TT?!

1 Like
#41

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 !

4 Likes
#42

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!

1 Like
#43

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).

1 Like
#44

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…

3 Likes
#45

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.

3 Likes