Grid ops / integration



yeah, sorry, at this point it’s a race between me finishing the firmware or updating the docs, but i really need to describe it somewhere…

as @ghost mentioned, on live screen use CTRL-G to turn the grid visualizer on. press it again to enter the full view, then again to go back to live (all the usual keys still work so you can always switch to scripts/pattern view when you in grid visualizer view).

CTRL-arrow keys will move the selection. CTRL-SHIFT-arrow keys will define an area. the right side shows the current position and the area width and height. CTRL-Prt Sc will input them in the command line - handy for creating new controls. CTRL-space will emulate grid press. CTRL-/ switches between the upper and lower halves.

when you in full view you don’t have to press CTRL - this is so you can use grid scenes without a grid easily.


With the MLR scene, did you have to use a delay on the trigger pulse after setting the slice index on the 301? I’m making a slice triggering scene and I’m finding that I need to set a ~12ms delay on the trigger to have the right slice be set. Was that your experience too or did you find a better workaround?


to get slice selection working reliably on er-301 here is what i did:

  • a fixed delay unit after the trigger, set to 100% wet and 11ms. not sure if a shorter delay would work, need to experiment with it some more

  • sample player mode set to 12TET, this means for note selection i can simply do CV 1 N X where X is the slice number


ooh fixed delay on the 301 side is a good idea. do you know if the cause of the lag on the teletype side or the 301?


yeah, doing it on the er-301 side is really neat as it simplifies scripts quite a bit!

the lag is probably just due to the fact that CVs can’t change momentarily, and it’s likely on both sides. i’m curious though, will check with a scope when i get a chance.


Is scene backup and restore working in the latest build?
If there’s a parsing problem with one of the scripts, does it cause all scripts to fail to restore?
I have 22 scenes, most of which I’ve edited in a text editor on a computer (yes, I know that’s a no-no, but seriously?) I know I need to be on the lookout to ensure that LF line endings are in use. Any other gotchas I should be aware of?


there were no changes to the USB code, other than adding the grid part. i am able to load my scenes with no issues with the latest grid build.

i would have to look at the code but i think if one scene fails to load it shouldn’t affect other scenes (and if you had a typo in a script it just won’t load that line). line endings will definitely be a show stopper.

can you send me an example of a scene that does not load? are you able to load any other scenes?


At the moment zero scenes are loading. hmm.


zero as in other, non grid scenes as well? can you try one of the default scenes?

if those don’t load either, can you try with the official firmware?

also, can you describe what actually happens - does it say “write / read” with dots appearing when you plug it in? or nothing happens at all? do you get garbage in scene description or are they just empty?


Once the PR from @sliderule happens and 2.2 beta starts to pick up steam towards moving to official release, will we see the merger of Grid ops into the main branch?


do you mean grid version getting the 2.2 features? at this point i’m not planning to rebase off the master (once the 2.2 PR is merged) until the grid integration is complete. rebasing will be non trivial as there are several conflicts between the 2.2 and the grid branches, and i would prefer to keep my focus on completing the grid integration.

so my plan is:

  • finish grid integration
  • rebase and probably release one more beta that will have both 2.2 and grid features
  • submit a PR
  • update grid studies and create more scenes for the teletype code exchange

progress update: not much to report unfortunately, it seems being semi-retired makes one way busier than actually having a full time job! i’m trying to free my time for coding but things keep coming up. this should change next week, hopefully, at least until the holidays arrive…


have you ever considered allowing storage of values besides 1 and 0 in a button? could be a great place to sneak in values and syntactically if you are representing sequence steps with buttons, being able to use the value of the button rather than looking something up in the tracker columns might be a lot cleaner.


so, basically, if you do G.BTN.V 1 5 then when the button 1 is pressed G.BTNV would return 5? something like this could be done. the problem with this approach though is that you would have to use scripts to set these values (the beauty of using pattern data is that it has its own tracker editor and is persisted with the scene).


yea that is more or less what i would have in mind. for some uses, tracker would be preferable, but being able to set >1 values would be very useful when using a held button in one group and then setting its value with the press of another button from another group. for situations like this, i think it would help write more concise code.


i like the idea, and from the language perspective it can easily be added without changing anything or introducing any new ops, so i do want to add it.

this does mean though that i will need to introduce a couple of breaking changes - these values have to be stored to flash/usb when storing a scene. button states are already stored, not storing values would make things not intuitive. this means that older scenes might not load properly - i will need to think of a way to avoid that.


Just put along a little polysynth together using the grid operators and the TELEX expanders. Check out the post and a video over in the expanders thread:

Big shout-out to @scanner_darkly for how amazing the grid ops and visualizations are. They are crazy-easy to integrate with and unlock a tremendous amount of power.


so i’ve been thinking more about being able to assign arbitrary values to buttons and i realized i missed an important point. “value” for a button is also a state. so setting a value for a button means changing its state, and assigning a non zero value would have the same effect as pressing the button, which wouldn’t be desirable if you just want to assign a value.

this means adding this would necessitate separating the notions of “state” and “value” for buttons and introducing separate ops to set and get a value. but if we do that, it becomes something that is not really connected to button functionality, it just uses buttons as another way to store/retrieve values, which to me doesn’t feel right… patterns feel like a more appropriate mechanism for something like that.



I have a question about the Simple Sequencer in your study guide. How doe she last line, G.CLR; G.REC A 0 1 8 -3 -2, work? First, does G.CLR clear the whole grid each pulse, and then the whole thing gets re-written, or is it just clearing a single fader?

Second, what is the rectangle command doing? I assume something to do with the faded ‘progress’ bar? But if -3 and -2 are the fill and border…how do those negative numbers interact/work?



sorry to chime in, but I found myself in a similar situation just yesterday and noticed the grid ops reference (a bit burried on the wiki), it should answer your questions


to explain what G.CLR does exactly i need to explain how grid rendering works first.

there are 2 layers - one for controls (buttons, faders etc) and one for explicitly set LEDs. the control layer gets rendered first, and then anything set with G.LED, G.REC or G.RCT will be rendered on top of that. if you didn’t set any individual LEDs (or set them to level of -3) they are essentially “transparent”.

since you only have limited power over how grid controls are displayed (say, pressed buttons are always displayed with maximum brightness level of 15), this gives you the ability to fine tune the UI by drawing on top of other controls. say, you could hide a button by drawing a rectangle over it.

this wouldn’t be very useful by itself but it becomes more so if you use the 2 special brightness levels: -1 dims anything underneath, and -2 brightens it. the simple sequencer puts it to good use by using it to highlight the current step. so in this line:

G.CLR; G.REC A 0 1 8 -3 -2

G.CLR will clear all the previously set LEDs (please note this does not clear controls, just LEDs that were set with G.LED/G.REC/G.RCT). since we don’t set any other LEDs, just the current step, when we advance we can simply clear all and redraw (otherwise we’d have to clear the previous step with G.REC, which would be cumbersome and take more script space). and then we draw a rectangle over the current step with width of 1 and height of 8, fill is not used here (so just set to -3) and the border is set to brighten (-2).