but why would you ever want to use raw key press/lift or led other than connecting it to a grid operator? i guess one case would be supporting non grid controllers
that’s why. maybe i want to use input from a HID device and output to screen drawing operators, or use midi. i don’t know about ORCA but for example STEP and LIFE aren’t really very grid specific.
it doesn’t really seem like a big deal to me to accept three arbitrary numbers (or two, if preferable) as standard operator inputs, instead of from a lower-level handler. but this is just a thought.
for led output it would definitely require some refactoring as it’s just so easy to take advantage of being able to refresh the whole matrix at once rather than updating individual leds (unless it outputs every led on each refresh, probably not a good idea).
hm, i’m not sure i get what you mean. i’m looking here:
[ https://github.com/scanner-darkly/monome-mods/blob/master/orca/main.c#L378 ]
and saying, i dunno, turn this:
for (u8 i = 0; i < 4; i++)
for (u8 led = 0; led < 16; led++)
monomeLedBuffer[64+(i<<4)+led] = led < (counter[i] & 15) ? 15 : 0
```
into, like:
```
for (u8 i = 0; i < 4; i++) {
for (u8 pix = 0; pix < 16; pix++) {
net_activate(INDEX_OUT, 64+(i<<4)+pix);
net_activate(VALUE_OUT, pix < (counter[i] & 15) ? 15 : 0);
}
}
```
you see? there is an output that indicates a pixel index, and one that indicates the value at that pixel. now i can plug this into a SCREEN operator. (well, with some tweaks.) i would also tweak the GRID operator to accept the same input format. now the op doesn't have to care what kind of display its talking to. (assuming of course that all operators respect the L->R convention for update order.)
likewise i can make an op that produces (x, y, press/lift), or even just (index, press/lift) when i bang on my HID keyboard or midi thing or whatever.
i'm just brainstorming though, don't worry about it.
> (unless it outputs every led on each refresh, probably not a good idea).
hm, not sure what you mean. the monome driver in aleph/system/skeleton only uses quad refreshes. you change the pixel buffer whenver you want, and when the refresh timer comes around those get packed into quads. that's probably not what you mean though. you mean it would be too much overhead for an op to activate the network every time a pixel changes? that could be true, but it would totally depend on the downstream connections.
