I think the trick to keep in mind is that while many problems seem simple initially, there are often layers of complexity that pretend to be invisible.
For example, here’s an example of a network using only touch ops that will export a value of 2 to the brightness par of a luma level TOP when “y” is pressed, or when a timer reaches “done”.
base_keyboard_val.tox (1.37 KB)
That’s pretty straightforward, but there’s an interesting issue here - the keyboard operates input as a toggle button. That is, that the channel for the “y” key is true only when depressed, but goes back to 0 when released. The timer CHOP’s “done” channel will stay as true until re-triggered. So here we have a situation where it becomes important to know which behavior is intended.
You’ll also notice that the override takes the last value passed. So if you run the timer, the luma level will go to 2. When you press the y key the value stays at 2, but when you release the y key the value will drop back to 0 (as the state of the y key is now at 0).
Another question that begins to develop here is “what does a neutral state look like, and what resets your system to the neutral state?” Isadora makes a few assumptions for you about how you’re likely going to work - which is great, but it also hides from you the nuance of what’s really happening behind the scenes.
From a theatrical perspective I would think of these kinds of situations as state functions that were tied to cues - in cue 01 I want the value to be 2.4, in cue 02 I want the value to be 1.0. In this paradigm the the current cue denotes desired state of the end value (tweening and transitions are of course another thought all together). For installations these days I often think of these problems in terms of state machines that need to navigate between previous, current, and next values.
When I was first making the change from Izzy to Touch I found these kinds of issues very frustrating as it seemed logical that a system should behave in a particular way - now I appreciate the granularity in this regard as it frees the designer to make choices about exactly what should happen and when.
Another good example of this kind of granularity is in this thread:
derivative.ca/Forum/viewtopic.ph … lit=buzzer
The problem seems light a pretty straightforward one, but the more conversation happened the more important it became important to really understand the specific details about what the entire series of events needed to look like.
I’m sure there’s an ops only solution - it just comes down to what the exact logic behind state changes needs to look like.