Grid ops / integration

Just a quick :heart: :heart_eyes_cat: :skull_and_crossbones: :woman_cartwheeling: :exclamation:

I only just installed the beta and haven’t done anything really… But the work you put in. Simply awesome.

…and of course everyone else involved in the development of TT, Grids, monome as a whole.



ok, here is the breakdown of the pong scene (i’ll optimize/refactor it and add it as a grid teletype study when i get a chance). the video:

as a quick recap, you have a dot that moves horizontally or vertically on the grid. pressing anywhere creates a block. when the dot hits a block it changes the direction randomly and sends a trigger. CV 1 is based on the horizontal position and can be used for pitch, CV 2 is based on the vertical position and can be used for modulation. CV 3&4 are derived from horizontal and vertical speed.

A 8; B 4; C 1; D 0
G.BTX 1 1 1 1 1 1 0 0 16 8

A is the horizontal position, B is the vertical position. C and D determine horizontal and vertical speed (basically, this is the amount that gets added to A and B on each step).

G.BTX id x y w h latch level script columns rows generates 16 rows and 8 columns of 1x1 latching buttons starting with button 1, so we cover 128 grid completely. level here is the brightness level for buttons that are not pressed, we just want it to be unlit, so 0. for this scene we don’t need to do anything whenever a button is pressed (we’ll just need to check the current state of a button at A,B coordinates), so we set script to 0 (you can assign scripts to buttons so whenever a button is pressed the script assigned to it gets executed).

PN 2 0 PN 2 1
PN 3 0 PN 3 1
PN 2 1 A; PN 3 1 B
A + 1 % + A + C 15 16
B + 1 % + B + D 7 8

G.LED PN 2 1 PN 3 1 9
G.LED PN 2 0 PN 3 0 5
M SCALE 0 V 10 V 1 50 PRM

these 2 scripts move the dot around and draw it. it looks more complicated than it actually is - on each metro tick we basically clear the grid (G.CLR) and then draw the dot (G.LED A B 13). 13 is the brightness level. the rest is just using patterns 2 and 3 to store the previous 2 coordinates so we can draw a nice looking trace (2 more dots with lesser brightness). finally, we update A and B by adding C and D and wrapping the values. (oh, and we update M speed based on the knob value).

Z + A * - B 1 16

TR.P 1
CV 1 N A
CV 2 V B
CV 3 V + 2 C
CV 4 V + 2 D

ELSE: X -1
ELSE: D 0; C X

finally, this is the block collision logic. first, we calculate which button corresponds to A,B coordinates and save it to Z. G.BTN.V Z then gives us the state of the button, 1 if it’s pressed and 0 if it’s not pressed. if it’s pressed we generate a trigger and update CV outputs (script 2) and then generate a new random direction (script 3). that’s it!

plenty of room left for further experimentation, say, you could also set metro speed based on position (something like M ADD 50 MUL A 10), or use all 4 triggers and choose which one to trigger based on direction.


brilliant, thankyou!


i was hoping you would post here, awesome patch! the sounds work so well with the visual part.


little typo i noticed in the TRIGGER SEQUENCER study. the I script should be G.BTX instead of G.BTN as it is now so you get a TOO MANY PARAMS error. And the M script should be 8 not 7.

Thought you’d want to know. And also, this is so cool. thank you :slight_smile:

1 Like

thank you, i’ve updated the study! i wrote it before i changed some of the ops (the trigger sequencer was actually the scene that made me reconsider some of them) and forgot to update in several places. i think the script linked in the study is the correct version, pretty sure i tested it, but i’ll double check both the study and the script.

1 Like

Will there be more monome switches produced in the future @tehn?

no, but the “offworld” will be available as a kit and built soon: Ansible & grid / power issues?


@scanner_darkly – JUST installed. super excited to start, thank you for all the incredible work on this.

two things:

  1. when I imported an older scene with C# in the description, it imported the title and description but truncated the # and left the scripts blank. is this normal for any TT distro, when reading scenes in from the USB that have # in their descriptors?
  2. my grid studies brain is having a bit of dissonance with the x y coordinates. the first button in the first row and column is typically 0,0 but the beta uses 1,1. since TT’s tracker is also zero-based, I wonder if the grid implementation shouldn’t be as well?

just q’s for thought!

1 Like

# in the description - looks like an existing bug. i confirmed by creating a scene with # in the description and loading it with the official 2.0 version and it did cut everything off after the #. i submitted the issue:

grid coordinates being 0-based - yes! i would actually prefer it this way, it also simplifies grid arithmetic as you won’t have to do - ... 1 or + ... 1 in many cases. don’t remember why i did it this way, the language unfortunately is not consistent when it comes to things being 0- or 1- based, but i agree this is a better choice (and patterns being 0-based is a good argument in favour of this as well).

which reminds me - i should mention that the grid extension is still a work in progress and will likely change based on the feedback here. so any ideas for improvements are very much welcome!


my own vote is for 0 index on coordinates, but i’d be curious to hear if you had a rationale for 1.

my rationale for 1-based for addressing outputs, kria params, etc, is that 0 is a convenient “all” function. i don’t see this being an advantage for the grid.


i think i might’ve considered it to be more non coder friendly… also when documenting ops it’d be weird to say “if you do G.LED 0 5 15 you should see a brighly lit LED in row 6” - this one is probably not such a big deal.

and yeah, remotes was one of the things that also made me think that 1-based approach was the defacto standard, patterns being one exception. i like the reasoning for this though, nice to keep 0 as a special value for remotes.

glad this got called out, my personal preference is also for 0,0 based coordinates. i think i’ll also change control ids to start with 0 as well.


one of the most interesting use cases i had in mind for grid/teletype integration is meta sequencing - using teletype scripts to control trilogy/ansible and using grid to control the scripts. here is an example of the pong scene used to control orca transposition and some other parameters:

this can be especially powerful if you use it to control multiple sequencers at once.


That’s gorgeous. …

1 Like

Been following over the past few days and this looks incredible. Between this and the possibility (inevitability?) of O|D collaboration, I’m leaning closer toward shifting some real estate toward monome.

1 Like

ok, a proper demo for metasequencing :slight_smile:

teletype trigger sequencer scene:

  • row 1 resets orca
  • row 2 transposes one of the sequences
  • rows 3&4 set position on ansible cycles 1&2
  • rows 5&6 reverse rotation on cycles 3&4

ansible controls waveforms and filter cutoff. i had space left for x/y pad, so that controls delays.
the cool thing is you can still control orca and ansible directly!


Quick clarification - Ansible Satellite doesn’t exist today? I can’t find anything on it. Is it an alternate Ansible firmware? I’d love to test the beta, but I don’t have an ext5v [1] or switch. I do have an Ansible and a TT though.

[1] - I bought an ext5v, but it was stolen off the UPS cart. An extended UPS reimbursement effort ended in me getting a trilogy compatible power supply in the meantime. Now i wish I had re-ordered the ext5v. They’re hard to find, I hate that someone took one out of circulation that I’m confident has no idea what they stole. It’s probably at the bottom of Boulder Creek.

1 Like

i’m waiting for parts to arrive (next week) and i’ll have the new all-usb “offworld” power solution ready and for sale on the site…


This sounds pretty great…will pick one up for sure.

My situation worked out fine for me. I ended up with a Row Power 40. No regrets.

ansible satellite doesn’t exist yet, just an idea, but i’m hoping to find the time to work on it at some point. actually surprised there hasn’t been much response to this, i think this could really be great for small set ups, especially if you have something like an ansible satellite / ww combo with ansible running grid scenes. you could edit scenes on a teletype and transfer them via usb stick, or you could just use the scenes posted on the github.