this is due to a firmware bug in the arc. it does not handle data line disconnection gracefully. the grid works fine.
@scanner_darkly i was looking at the grid ops and wondering: is there a way to detect if multiple buttons are currently pressed? use case: given a row that represents a 16-step sequence, i want to allow selecting a subsequence on that row by pressing two buttons at a time that would identify “start” and “stop” points
good question, it helped me discover a minor bug (“transparent” brightness level -3
is not supported for grid controls, only LEDs), thanks! will fix this in the next version. we can work around it for now though.
now, in general, if you want to track hold+press you would use momentary buttons as their state reflects whether the button is pressed, so you could simply use IF G.BTN.V ..
to check that. for your scenario it’s a bit more complicated as we don’t want to be checking all 16 buttons in a row. let’s use a variable and set it to X
coordinate of the last pressed button. when a button is released we’ll set it to -1 to indicate nothing is currently pressed. let’s use Z
for this, execute Z -1
and add it to the I
script.
now create your buttons (i’m using 1 row as an example here):
G.BTX 0 0 0 1 1 0 0 1 16 1
this creates a row of 16 momentary buttons that trigger script 1 when pressed. and here is our script 1:
I G.BTNX; T G.BTNV
IF && ! T EQ I Z: Z -1; BREAK
IF ! T: BREAK
IF EQ Z -1: Z I; BREAK
A MIN Z I; B MAX Z I
I
stores the X
coordinate of the button, T
stores the state: 1 is pressed, 0 is released (have to store these in variables so the rest of the script fits). 2nd line means: if a button is released, and this is the button that was pressed last (so Z
has its X
coordinate), reset Z
back to -1 and exit. this is so that we properly clear Z
for single presses.
3rd line compares G.BTNV
(which is stored in T
) to zero, if it’s true it’s a release and there is nothing to do, so we break. finally, we know it’s a press, so we check if there is a previously pressed button (Z
is not -1). if not, we just set Z
and break.
at this point Z
contains the previously pressed button, and I
contains the currently pressed button (or, more accurately, their X
coordinates), and using MIN
and MAX
we can get our start and end points (which i store in variables A
and B
here).
one problem here is that we can’t use these momentary buttons for the actual sequencer. so here is a trick: just add latching buttons on top of the momentary ones - but make sure to give them ids that are higher than the ones used for the momentary buttons (controls get rendered in the order of their ids, so you don’t want your momentary buttons hiding your latching ones).
one more trick: to display the currently selected loop the easiest option is to draw a rectangle using the special brightness level of -2 (“brighten”).
so, typing all this is a good way to feel the pain and it’s just not a very elegant solution to something that would be a fairly common scenario. i’ll think of some better mechanism to handle this, maybe a couple of ops to check if there is a previously pressed button in a group.
Thanks for the thorough answer! I’ll try these techniques soon.
so, typing all this is a good way to feel the pain
and it’s just not a very elegant solution to something that would be a fairly common scenario. i’ll think of some better mechanism to handle this, maybe a couple of ops to check if there is a previously pressed button in a group.
Awesome! My hope was this might motivate some additional ops I am a new TT user, but I see TT has patterns. I wonder if one or more patterns could be read out for a particular group. The patterns would indicate, e.g., currently pressed buttons in the order they were pressed—either by ID, or X/Y separately, etc. Not sure if this is idiomatic or not…
there is no way in TT to return an array of values from an op, but something similar could be done by providing a method that returns the total number of pressed buttons and then lets you read them using an index. i think for this purpose it might be an overkill though, something simpler like getting an id of the previously pressed button might be sufficient (basically, providing an op that would do what Z
variable does in my example above).
another option could be having ops that give you the id of the leftmost/upmost/rightmost/downmost pressed button in a group (i’m leaning towards this option).
new beta! the main addition is fine (gradient) faders. this version also includes er-301 and faderbank support and new pattern and telex ops added by @bpcmusic.
i have to run so have to be brief, i will update the wiki later today or tomorrow. to use new gradient faders a change was made to G.FDR
/ G.FDX
/ G.GFD
/ G.GFX
. i’ll illustrate with G.FDR
, the new format is:
G.FDR id x y w h type levels script
dir
parameter was replaced with type
parameter. it’s backwards compatible, but now you also have additional types:
- 0 - coarse, horizontal bar (same as before)
- 1 - coarse, vertical bar (same as before)
- 2 - coarse, horizontal dot
- 3 - coarse, vertical dot
- 4 - fine, horizontal bar
- 5 - fine, vertical bar
- 6 - fine, horizontal dot
- 7 - fine, vertical dot
for fine fader types level
parameter now means levels
- instead of brightness level it indicates how fine a fader is. you can have up to 16 levels per button. in fine faders 2 edge buttons are reserved for inc/dec. pressing on other buttons sets it to “average” for that button. pressing and holding a button and then pressing another will “slide” value (script gets triggered on each value change).
as you see, dot versions are added - this is a nice way to implement radio buttons. G.FDR.N
was changed in this version so that it’s 0 based now.
here is an example:
teletype.zip (132.6 KB)
teletype.hex (446.8 KB)
forgot to add, the grid emulator is now also complete. i changed the selected area to be shown with dotted lines, and you can now see control outlines by using CTRL-\
combo - very handy!
just a quick question: is there (the possibility of) an op to set the grid’s global brightness (ie. equivalent of the /monome/grid/led/intensity 0-15 serialosc command) ?
Asking this because i have a 128 grid kit built with bright leds and i like to set global brightness to a reduced value when not working in the sunlight / outside (at full brightness it is borderline blinding especially at night / in a dimly lit room).
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.
perfect, thank you. (now i scrolled back to the first post and found the link to the docs ^^ )
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.
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!
Holy shit, that is really awesome!
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.
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.
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?
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.