Grid ops / integration

Thanks ! (12345678910)

1 Like

Thank you :wink: i’m following this tread with great attention !

it seems to work perfectly.
There was a bug where there was an offset off 1 step in the generated CV, but it’s corrected here :

PN 2 A + 1 PN 2 A
PN 2 A 0; G.REC 0 A 16 1 0 0
PN 0 A % + 1 PN 0 A 16
CV + 1 A VV MUL 63 PN 0 A //Need to put this line here. MUL 63 scales it full range. (needs adjustment for the ER-301 inputs)
G.LED PN 0 A A 15

1 Like

i’ll try to add stop buttons.
Now the tricky part is how to make ‘inner loops’, where pressing a button while holding another one defines a loop…

yeah i wasn’t sure what range er-301 would expect, but can be easily adjusted to what makes sense. basically, PN 0 A is the current position between 0 and 15, and then you just scale it to whatever range you need.

stop buttons - i assume per track?
interesting feature with inner loops - does it need to loop only while the buttons are pressed? or does pressing 2 buttons simultaneously defines a loop that continues even when the buttons are released?

inner loops was indeed tricky to add but doable! mlr2.txt (1.8 KB)

there were several changes, i’ll do a more detailed write up later, here are the main changes:

  • pattern bank 3 is now used to store the starting and ending points for each 4 of the tracks
  • pattern bank values 8-11 store the position of the last pressed button or -1 when a button is released
  • when a button is pressed and there is a previously pressed button it will set the loop points based on those buttons
  • faders length reduced to 8 (you probably don’t need to divide by more than 7 anyway) and 4 buttons in the bottom 4 rows in the rightmost column are start/stop buttons (don’t forget to press them as they are stopped by default)
  • when advancing a track we just add the value of the corresponding start/stop button - if it’s pressed it’ll be 1 and 0 if not pressed which is exactly what we want
  • there is a change in how we set LEDs to show the inner loop when it’s defined
  • you were right, CV update was off by one! don’t forget to change the scaling in the script i posted.


Thank you again for this. This is tremendous.
And also a great lesson of TT coding ! i’m learning a lot from this code.

in action :


hi @scanner_darkly
with all this new implementation, do you think it could be possible to map WW and Kria (Ansible) monome layouts to a monome 256? that would be pretty awesome :wink:


via Teletype, it’s made possible.

1 Like

great to see it in action, thanks for posting it! i’m going to refactor the script, it’s getting confusing with how track variables map to pattern values, so instead i’ll change it so that each bank corresponds to a track. once that’s done i want to see if @mlogger request is possible and if there is room to add the ability to record.

do you mean using ww and ansible with grid 256? or something else? if the former, i posted a 256 version of white whale a while ago: White Whale mod for grid 256 [beta]. ansible would require a firmware change as well.

1 Like

i mean using ww on the upper 8 rows and Kria on the lower 8
but i’m konig to try this ww firmware right now :ok_hand:

1 Like

Sorry i didn’t understand you wanted to use them at the same time.

unfortunately that would require combining functionality from both into a new firmware, a non trivial task…

ok, not a big deal, just dreaming :wink:
thanks anyways for that awesome work

1 Like

i think i finally got the mlr style scene working including recording… will post it in the next couple of days, need to clean it up a bit. once i figured out how to setup er-301 things just worked as expected which is amazing. er-301 and teletype is insane combo.


Ah, the holy grail! You found it again! Maybe we will keep track of it this time. :wink:

i thought of a feature ‘request’ :

More precise/unstepped values for faders.
You could control the faders with a press+hold of the destination (not necessarily to get reached). The speed to reach the destination would be variable.
The last button of the fader could use variable brightness to display that it’s not ‘full’.

Thoughts ?


Also another one :

“Grid Memory”
a collection of memory slots that you can use to store values and states of all (or grouped) grid elements.
That would be great to recall sequencer presets, for instance.

i like this idea. i will need to rework the visualizer part and there isn’t enough space to display numbers for all 16 groups the way it displays the 8 groups now, but i don’t think numbers are really needed, i will change it to dots or something similar.

i did have group versions of button and fader ops but thought they were too unwieldy and removed them… but i think it makes sense to bring them back. so basically it will be something like:

G.GBTX group id x y w h latching level script countx county


do you mean being able to have sort of like a slew when changing fader values? the problem with this is - teletype is not really set up to track continuous changes. say, if we had this ability and a fader is slowly changing its value from A to B when should we trigger the corresponding script? if we just trigger it when it reaches B then we don’t really gain much. the workaround is using a very fast metro script, but this really feels hackish…

i do agree it would be nice to have the ability to have finer control over fader values, otherwise they don’t seem all that useful. so yeah, we could use varibrightness and have some button combo to increase/decrease value in smaller steps. i will add this to the list!

this is probably less likely to happen… the reason is - if we had additional memory slots i would expect them to be stored in flash when i store my scene. we have some space there but storing grid state takes quite a bit of space, and in the future we might have new features that will also need to use storage, so we have to be careful what we allocate it for.

a workaround for this is using our existing infrastructure in the form of patterns. it’s really easy to do something like L 0 15: PN 0 I G.BTN.V I. with upcoming bitwise ops it will also be easy to pack 16 button states into one pattern value (i have example of this above in the pattern canvas scene). i think what makes more sense is expanding the number of available pattern banks to 8 (or even more).