#296

you can use G.DIM x op for that. it will dim the overall brightness by a specified amount (0…14, 0 is the default value). it’s not based on /monome/grid/led/intensity but simply reduces brightness level for everything that is rendered.

#297

perfect, thank you. (now i scrolled back to the first post and found the link to the docs ^^ )

1 Like
#298

new beta - now with 2.2 features included! i will be posting new betas in this thread from now on: Teletype 3.0 but for discussing grid integration related things we should continue using this thread.

what’s new in the latest beta for grid integration specifically?

unfortunately, i had to change the grid shortcuts in live screen to use Alt instead of Ctrl. this was mainly to avoid collision with the new feature (using Ctrl-arrows to move cursor by words).

to help with the transition i added a new feature - now you can emulate a press and hold. to do so select an area more than 1x1. now if you use Alt-<spacebar> to emulate a grid press it will emulate pressing on the start cell and then while it’s pressed it will emulate pressing on the end cell. this can be also used for fader slides (which wasn’t possible in grid visualizer before).

i also adjusted brightness levels - the levels of -1 (dim) and -2 (brighten) will now stand out more. also, for active controls (buttons that are pressed etc) it will now use the level of 13 instead of 15, this way when it’s brightened the change will be visible (good for displaying the active step in a sequencer, for instance).

other changes: bug fixed in ops setting fader level(s) (it would reset value for coarse faders), and controls now also support brightness levels of -1 and -2.

7 Likes
#300

reposting @burn’s awesome snake scene (i checked if i could repost), it totally deserves to be here:

really good example of using grid integration. love the navigation button group!

9 Likes
#301

Holy shit, that is really awesome!

1 Like
#302

how are you finding the switch now? my switch finally arrived and i just tried it, it works but very intermittently. sometimes i have to switch several times before it properly recognizes either grid or keyboard. i also tried pressing buttons half way so that both are off before switching but didn’t seem to make a difference.

#303

I still couldn’t be happier with mine. I also tried another smaller one who seemed to be more of a digital switch, it didn’t work, but no complaints with the one I posted above. Stupid question: did you also try with different cables? I had some funkiness in the beginning, which was resolved by using another cable. Before I had to power cycle with monome switch a lot.

#304

i’ll give it another try with different cables to see if it makes a difference (my switch looks exactly like yours). how are you powering yours? ext5v / offworld / switch?

#305

monome switch. and doepfer psu3 for reference.

1 Like
#306

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.

2 Likes
#307

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?

1 Like
#309

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.

1 Like
#310

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

1 Like
#311

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.

1 Like
#312

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.

1 Like
#313

I FEEL SO MUCH BETTER, THANK YOU. ah.

was that documented already? that’s wicked helpful.

glad for the unintentional bug identification!

1 Like
#314

d’oh! thought i updated the wiki. updated it now: https://github.com/scanner-darkly/teletype/wiki/GRID-OPERATORS

thanks for noticing and helping discover a bug!

2 Likes
#315

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.

#316

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?

#317

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.

2 Likes