monome ops need added focus functionality

[tehn]

• [x] do not send LED data when no focus
• [x] clear and update LEDs on focus

[tehn]

this will be a general guideline for focus management on monome ops

[tehn]

this now applies to op_step as well.

[catfact]

when does op_grid send LED data with no focus? with no focus it shouldn't handle keys. it only updates LEDs from key handler.

sorry, just saw that you're talking about LIFE, my bad.

for step / life, can't you just test the focus in the input function?

ok, i added a function to bees/src/net_monome.c called net_monome_grid_clear() , and it is called from grid and step when focus set to 0. so that seems fine so far. commit efa5ae4

[catfact]

hm, it's actually not sufficient cause e.g. step then has to redraw its state when it gets focus back again. pretty clear though, will leave it to you to add a static 'refresh all' func to that operator..?

[tehn]

op_grid works correctly because it doesn't send LED data when not focussed based on its functionality. life and step can run without grid input, so the leds need to be throttled. it's easy to add, i really was just noting that i needed to do this.

basic grid op rules:

1. when focus transitions to 1 (from 0), clear and redraw
2. when focus is 0, don't draw

that's it.

On Thu, Mar 27, 2014 at 10:48 PM, ezra buchla notifications@github.comwrote:

hm, it's actually not sufficient cause e.g. step then has to redraw its state when it gets focus back again. pretty clear though, will leave it to you to add a static refresh func to that operator

Reply to this email directly or view it on GitHubhttps://github.com/tehn/aleph/issues/169#issuecomment-38884252 .

[ghost]

So having thought about this a bit I think the best way to handle the focus-switching is for 'focus' inputs on these monolithic grid ops to be stateless. By that I mean they always display 0 on BEES inputs page.

• Whenever the focus input for an op is banged with any number, that op grabs focus from whoever currently is holding focus.
• 'having focus' means that op will receive button presses & it has 'write access' to the grid LEDs.
• for starters, every op can transmit LED data regardless of focus, & the driver can ignore all but the focused op.
• each grid op must store the state of all it's internal grid LEDs independent of actual values on the physical grid
• when an op grabs focus, it updates the whole grid to match up with it's internal LED state
• ops do not have to be 'notified' when they lose focus

A possible optimisation (which adds some complexity) would be to also have the backend driver notify an op when it loses focus. That way it can simply not send the LED data to backend driver... But I have a feeling this may not make a huge difference to performance.

Pretty sure that plan will work, and work well, though carrying out the plan probably more challenging than maybe I'd like! @tehn, @catfact either of you see any pitfalls to this method of swapping grid focus between apps?

[catfact]

Whenever the focus input for an op is banged with any number, that op grabs focus from whoever currently is holding focus.

that seems ok. it has drawbacks:

• mainly, it's a mite confusing for UI. you can't scroll through the inputs list and see who has focus.
• it seems relatively easy to accidentally bang something, from preset recall or on scene load, that you didn't mean to. when the input value is 1/0, accidental bangs don't matter as long as the value is correct.

each grid op must store the state of all it's internal grid LEDs independent of actual values on the physical grid

agreed, that's necessary, one way or another, for focus switching to work well. it can't work now.

it updates the whole grid to match up with it's internal LED state

this i'm a bit unsure on. i'm coming around to what i think @scanner-darkly was proposing on the forum, which is that the driver needn't keep its own state at all (except as a fallback); instead it points at the buffer of whatever op has focus.

otherwise, seems like the options are:

1. periodically copy from the focussed op, from the refresh timer i guess. as you say this shouldn't really be a big deal, but it's not a lovely solution.
2. force the operators to explicitly request refreshes. do the copy at that point, set dirty-flag for appropriate frames, and wait for the refresh timer for bits to actually move out. drawback: operator might ask for way more copy steps than is really necessary.

but i'm still not really seeing the benefit of copying since the driver presumably needs to know about the focused op address anyway.

[ghost]

that seems ok. it has drawbacks: mainly, it's a mite confusing for UI. you can't scroll through the inputs list and see who has focus.

Yes I thought harder about this and come round to your point of view on this. Additionally: https://github.com/rick-monster/aleph/blob/dev/apps/bees/src/net_monome.c#L65 This focus flag can be replaced by a pointer directly into the operator's focus input - so the glue layer will be responsible for updating the focus input when one op steals focus from another. this i'm a bit unsure on. i'm coming around to what i think @scanner-darkly was proposing on the forum, which is that the driver needn't keep its own state at all (except as a fallback); instead it points at the buffer of whatever op has focus.

Sounds like the right thing to me - gonna make the necessary changes to driver on dev branch... (i.e putting the avr32lib merge to one side for a minute)

will pull-request this change back into avr32lib along with my serial comms changes on dev at a later stage.