Grid ops / integration



I’m just getting a grip on tt - this is my next task but can I say its astounding the amount of work you get through and its so selfless too. I’m looking forward to working through all this that you have created and thank you in advance. Bravo


Let’s say that I have a row of buttons, and I want one action to occur if I’m pressing just one button, but a different action to occur if I’m pressing two buttons on the same row.

What’s the best way to not trigger the “one button” action when trying to press two buttons for the “two button” action? Do I detect the first button press and then set a delay before I check to see if still only one button is pressed , or two buttons have been pressed in the meantime?

The use case is building a euclidian drum sequencer, where I can use two button presses on the same row to select loop length (aka number of spaces), and then one button press to select the number of pulses


normally for something like this you can use a button release instead of a button press. it’ll be a slightly different feel but if you use quick presses it shouldn’t be too noticeable.

it would look something like this:

set the number of pulses

the 1st line checks if there is more than one button pressed in a group (group 0 in this example). if there is we can define a loop (as an example here i’m storing the loop length to variable T).

the 2nd line makes it ignore button presses. if we make it past this line it means a button was released with no other buttons pressed.


My brand new Grid just arrived today which was purchased solely because of the 2.3 Teletype firmware release! Hopefully someone will get to work on the 2 in / 2 out switch so I can have the keyboard and Grid connected at the same time!


I have just such a device on my workbench… Grid + Keyboard + external power IN, 3 outs (Teletype + 2 others).
I’ve been pondering whether to make a few for sale. Honestly it’s just a 4P3T rotary switch and some jacks!


PM me your email and I’ll send Paypal right away :slight_smile:


If you have a good source for panel mount USB jacks, I would love to hear about it. :slight_smile:


Haha well there’s a pretty clear answer. Give me a few weeks with the design and then I’ll post back with results.


PCB mount jacks << $$panel mount jacks$$


I’d be interested in this.


i’ve been also collaborating with somebody on a possible switch solution, will share details as soon as i can. it’ll be great to have more options though, looking forward to what you come up with!


So, for the fader ops:

level is brightness level for coarse faders, max value level for fine faders

Is “max value level for fine faders” like a step amount when you’re pressing one of the always lit buttons that’s either on the top or bottom, left or right, depending on orientation? (Referring to the dot versions). This is what it seems to be specifying (though it is somewhat rounded/adjusted for fader length, I think) rather than the absolute max value that can be returned by G.FDR.V.

Or am I misunderstanding them?

Edit: I think I am misunderstanding as in another experiment I just tried, that doesn’t seem to hold up. :slight_smile:


for fine faders (whether dot or bar) level basically specifies how many distinct values you want that fader to have, regardless of its size. so you could have a fader which is 8 buttons wide but has 50 levels, for instance. the inc/dec buttons (which only fine faders have) always increment or decrement by 1.

you can’t assign just any number of levels, however, since varibright grids only allow 16 different brightness levels. so the maximum allowed value will be the width (or height) - 2 (2 buttons are always reserved for inc/dec) multiplied by 16 (and we need to subtract one since this is the max value, and the full range is 0…max).

basically, the idea is that you can only define levels that can be displayed with different brightness levels. you don’t have to remember the above formula, if in doubt just set it to some large number and it’ll limit it automatically for you (as a matter of fact, a good way to check what’s the maximum value is for a given fader is create it with some large number and then use G.FDR.L x to check what it is).

when you use G.BTN.N it will return a value in the 0…max range. G.BTN.V gives you that scaled to whatever the current range is for that group.

when i start on the grid studies again i’ll start with the one on faders :slight_smile:


OK, that makes sense. Originally I was thinking these fine faders were something that produced a smaller value range than the coarse faders, and would probably need to be used in conjunction with/added to a coarse fader. It looks like they are in fact far more awesome than that, and I’ll be using them quite a bit!!

Edit: Oh, wow, I just realized you can hold down the inc/dec buttons, and the fine faders keep responding. A tiny amount of slew on whatever CV they are controlling and you can basically simulate a continuous CV knob. These are really cool!


you can also slide between values. press on a value, hold, and then press on another and it will slide (the speed cannot be controlled right now but i’ll add an op for that in the future). if you slide to inc/dec buttons it’ll slide to max or 0.


This is amazing! I know there was talk about using ansible as a sort of grid satellite for grid ops on TT. Is this feasible? This might solve having to create a physical switch to connect both the keyboard and grid at the same time. Thanks for all your hard work.


My jaw keeps dropping in amazement. I’ve been excited about grid ops since I got the hardware, even from my sketchy understanding of what could be done. Seems there are a lot of functionalities I was thinking I would have to manually create in the scripts that are just included for “free”. This is really well thought out and going to be super useful!

Would love to see a speed control on the fader slide at some point. I’m glad you brought it up because it would feel kind of greedy at this point to ask given all you’ve already put into this. Also looking forward to more grid ops studies to see what else I’m overlooking!


not really feasible at this point i’m afraid, as it would require a major rework of the i2c implementation.

yep, that’s the idea, providing good building blocks that leave you more space for the actual functionality. funny thing, while scripting norns i found myself wishing norns had something similar, instead of having to do all the low level plumbing just to program, say, a button.


I feel like saying stuff like that is a dangerous game for you!


i should clarify, this was not meant as a slight to norns in any way. i do hope to get a chance to investigate adding something like that to norns when/if i get a chance (it’s somewhat related to a discussion we had on abstracting controllers / gestures, although that discussion was on a much higher level).