Grid ops / integration



monome switch. and doepfer psu3 for reference.


tried with different cables and no luck. i think it’s likely the switch itself - when i, say, switch to grid and nothing happens, i can then disconnect and reconnect the grid and it starts working.

glad it works for you though - it’s really handy being able to switch between grid and keyboard easily (although the grid visualizer really helps a lot to minimize that). i’m hoping that maybe somebody will make a proper switch (incl power for the grid) and will make it available to the community.


That’s a real bummer, wish this was a more general experience.

@madeinspace did you try something along these lines? (Usb switch). If so, how sucessfully?


yeah, 2.3 beta has all the latest grid stuff (and any changes/updates to grid integration will be posted as part of 2.3 beta testing). for any grid specific bugs let’s continue using this thread so we have all grid related discussion in one place.


I see that in your update above. I’ll delete the ask!


cool, sorted my question. running 2.3 beta 1.

I think G.FDR 0 0 4 16 1 6 16 1 should get me a super-fine, horizontal dot fader across (0-based) row 4 that triggers script 1, yeah?

but. when I press the far right edge button, the G.FDR.V value doesn’t seem to move much finer than coarse.

when the fader is at its minimum (even set G.GFDR.RN 0 0 16383 for good measure):
one press of the right edge button on fine gets me 1023 and moves the dot one button to the right.
selecting the next dot to the right on coarse gets me 1092.

using your fader Instagram video as reference, I think I’m doing something very wrong but can’t sort out what. :confused: it seems like a tap of the right edge button on a very fine (16-level) fader would increase brightness on the current dot by 1, till it gets to 16, then it’ll spill over the next button.

any redirect/confirmation would be rad! I love this integration and am really just trying to emulate the IG video you had posted.


so when you use fine faders the level parameter is not the brightness level like it is for coarse faders, it’s the maximum level you want your fader to have (the brightness level is not used in fine faders anyway, since brightness reflects the current value).

in your op level is set to 16, and your fader is also 16 buttons wide (14 if we exclude up/down buttons). this explains why fine adjustments are close to coarse adjustments. so what you want is to increase the maximum level to something much higher. you are still limited by 16 levels per button, so for a 16 wide fine fader that would be 14 * 16 - 1 = 223. if you want the finest fader possible but don’t want to calculate it yourself just set it to some really high number and it’ll limit it properly (and you can check what it is by using G.FDR.L).

it looks like i did introduce a bug in 2.3 though - if you select max level to a value higher than 127 it won’t work. will fix it in the next beta! but try it with 127 in the meantime, you should be able to see the difference.



was that documented already? that’s wicked helpful.

glad for the unintentional bug identification!


d’oh! thought i updated the wiki. updated it now:

thanks for noticing and helping discover a bug!


would it be possible to have the option to have the emulated button presses running even if that button/group is disabled ?
the advantage would be that the “virtual” presses are still running -automated button presses example- while you are on another page pressing buttons on the grid.


i think that might be a useful change, but only for G.BTN.PR / G.FDR.PR as you are explicitly stating your intent to “press” them. for G.KEY it wouldn’t make sense as you might have some disabled buttons / faders from previously executed commands that you don’t intend to interact with, and it would be confusing when they do. is that what you had in mind?

this seems like an interesting use case, can you describe it a bit more?


exacty, my intent in this case was for G.BTN.PR .
I’m trying to create a scene where samples are triggered mlr style with button presses and quantized to clock on the ER-301, and looped using the new pedal looper unit - looper controls assigned to buttons on the grid.
emulated presses are for the random triggering option, where I would like to have another page to assign probabilities for each step, and that’s where I had this problem with disabled groups. It would be of course possible to write this another way without using G.BTN.PR but its just much more convenient and it saves a few lines , I think.
hope that makes sense.


i’m still not entirely clear on your use case but i think the change does make sense (i thought the workaround could be simply calling the script assigned to the button you “press” but then you lose the ability to use G.BTNV \ G.BTNI etc shortcuts, and there are some other subtle differences between emulating a button press and calling a script directly). i’ll make the change in the next version.

this also made me consider what would happen in this scenario:

  • create a button and assign script 1 to it
  • in script 1 call script 2
  • in script 2 emulate pressing the button

my concern was it would cause it to freeze as it would enter an endless loop, but the recursion detection works properly in this case as well and stops it after 4 iterations.


thanks! those shortcuts were the reason why I used emulated button presses, plus I like to have visual feedback on the grid.
sorry I wasnt very clear about the use case; I’m still trying to find out how to write what I’m trying to do.
the short version is, the script is emulating random button presses when its triggered. I want to go to another page on the grid and change some faders while its still running.


@scanner_darkly really enjoying my time w/ the grid ops!

An issue I’ve become curious with, is that my faders seem to switch intermittently between moving instantly to a new value upon a press and moving to the new value with what feels like a slew. Had this problem briefly while making the fader group in the simple seq patch and have stumbled upon it again with a single fader in my own patch. In my patch I had this problem for a few minutes, then w/o a reason I could recognize the fader began working normally a few minutes later it returned to the slow movement between presses.

I’m getting this behavior in both the visualizer and the grid itself. Going back to the simple sequencer, I’m noticing that I curiously only have this issue on faders 2,5,7,9,10,12,13,14. As a shot in the dark, I tried G.RST and reinitializing the patch, and now the sluggish faders are 3,5,6,9,10 (where the other faders jump quickly to the new value).

While I’ve had this issue days apart, I also tried a reboot and now the sticky faders in the simple sequencer are faders 13,14 with the rest working as expected.

I did a quick refresher through this thread and a few searches I thought might bring me to this being previously discussed, so apologies if I missed a glaringly similar query above, but I’m curious if there is something I’m missing here?

I’m on the 2.3 beta 1



what you’re seeing is fader slides getting triggered due to “stuck” grid buttons. fader slides are triggered by 2 keys pressed simultaneously. for some reason sometimes it doesn’t get a release from the previous key, so to firmware it looks like 2 keys are pressed at the same time.

it’s actually easily reproducible in grid visualizer, if you press alt-space then while holding it press an arrow it’ll interpret it as the first button still being pressed (i used it to emulate press+hold this way before, but now it’s not needed as you can do the same thing by expanding selected area and then doing a press). i also noticed it happen sometimes when switching from keyboard to grid.

i just finished making a couple of changes, basically, disabling the behaviour described above (now if you move away from a pressed button it will automatically release it), as well as resetting any held keys when you plug the grid. i’m hoping these changes should address most scenarios. i should have a new beta likely tomorrow, for now the fix is basically pressing every button in a fader until you hit the one it thinks is held, after that it’ll return to normal operation.


new beta posted here: Teletype 3.0

what’s new for grid integration specifically?

  • “sticky” grid faders hopefully fixed, basically i did what i described above (cc @tambouri)
  • G.BTN.PR and G.FDR.PR will now work on disabled controls (cc @derz)
  • fine faders not working properly with levels higher 127 fixed (cc @Dan_Derks)

next beta will include some cool new grid ops!


After a night’s TT workout, I have not had any more issues w/ sticky faders. And P.HERE is working as expected while monitoring the pattern page

Also played w/ using L 0 15: $ 2 and calling I in the script 2. While I haven’t tried the fringe cases mentioned in the beta thread, it appeared to be working exactly as expected.

I think I lucked out w/ my issues being so close to a beta release, but that was an impressive turn around.
thank you


it was great timing, i literally just finished working on sticky faders when you posted :slight_smile:

thanks for testing, great to hear it’s working now! and thanks for reporting the PN.HERE bug, those are the kind of bugs that are difficult to spot (i checked other pattern ops and this was the only one that had the issue) but can really break the workflow when you’re in a middle of a scene and trying to figure out why it’s not working.


Mr. @scanner_darkly could you elaborate on the ‘horizontal’ and ‘vertical’ options for faders? I’m not quite grasping those settings in relation to the width and height settings. Seems like one has to manually set both the width and height to reflect which way you want the fade to go AND the fader options to the same setting, if that mkakes sense.