See also: Implementing Mirrors

Mirror

The Mirror ‘reflects’ an input with an output. It’s linear in that the values or dynamics of the output are concordant with the input. In our definition of a Mirror, the Mirror does not contort or misrepresent. There’s no distinct concept or purpose to the Mirror, nothing you can do with or to it.

Starting with the Mirror is useful because you:

1. Don’t have to design or have an initial creative leap,
2. The technical aspect is as simple as it can get, and
3. You begin to engage and gain some fluency with your materials

What we mirror can be thought about in terms of data and dynamics. Starting with a Data Mirror is a recommended first step.

• Data: mirroring at the computational level of numbers, booleans etc.
• Dynamics: mirroring at the level of dynamics of force, direction etc.

The goal when making Mirrors is to:

• Achieve correspondence of input and output, in either data or dynamics.
• Create a variety of Mirrors using different forms of input and output to probe your materials.

Data mirror

Here are some example Data Mirrors.

Analog/continuous inputs

• Light sensor level high, sound volume high
• Hand in the top-left of camera frame, circle positioned in the top-left of screen frame

Digital/boolean inputs

• Button pressed, light turns on

In the example below, the 0..1 value of the horizontal slider is mapped linearly to colour saturation. Thus, positioning the slider to the middle equates to about half saturation.

Be mindful of the qualities of the chosen expressive material. For example when working with colour, we might read meaning based on what colours are picked (eg. red being some kind of urgency or alarm). Try to avoid obvious significance-laden colours, text or symbols.

Perceptually, colour emitted from a screen will be experienced differently depending on the size of the area lit (eg. one pixel versus a 4K 31” display), other visuals around it, relative brightness of the display to the ambient space, and so on.

Try the same data mirroring, but:

• Larger, or
• Changing hue instead of saturation

Although we might begin by choosing a ‘quick and dirty’ means of expression, try different ways of using a material or entirely different materials. Reflect, too, on whether the experience is really in the interaction, or being overly carried by cultural norms.

Suggested steps for Data Mirrors

1. Hook into a data stream, make it print to the console or plot visually.
2. Interact in different ways, noting highs, lows, averages, jitter/noise etc of the input stream.
3. Map input stream to a form of continuous output.
4. Play with it, observe outcome. Refine data processing where necessary: inverting, normalising, averaging etc.
5. Try a different kind of output, ideally in a different modality or interpretation of input.

Dynamics Mirror

Another perspective of the Mirror concept is in the coupling of dynamics. In this case, we are oriented toward the bodily, felt dynamics of an interaction rather than the stream of data values we must build from.

Examples:

• Hitting a button hard means the light turns on with a higher brightness.
• If light level changes quickly, a short pulse sound is heard. If the light level changes slowly, the tone is lengthened and changes slowly.
• Stretching out your hand produces a ‘stretched out’ visual reaction, eg a line which gets thinner as it elongates.

Dynamics Mirrors are more complicated than the Data Mirror. But we retain the advantage of not having to imagine what the expression should be. By deriving the expression from the input, we set up a criterion, and will be able to judge how close or not we have reached the goal. This is useful for guiding our exploration.

The example below illustrates a Dynamics Mirror. The slider still sets the target saturation, but now it is reached with a speed corresponding to how quickly the slider is dragged.

When trying this demo, it’s also clear how the means of input - in this case, a rather insignificant, standard slider - affects our ability to produce or experience a particular dynamic. The small slider can feel finicky, precise.

For comparison, the demo below allows clicking and dragging within the whole panel.

As we begin to decouple the input from the output, we have to consider:

• Temporality: what is the rate of change of the expression? Do we need to decouple it from the rate of input?
• State: what state needs to be kept track of between discrete inputs or over time?
• Scaling: Rather than using the whole range of an input or output, perhaps we want to narrow them? Eg, perhaps in practice a force sensor only registers from 50-800, or instead of using 0-360 degrees for hue, we narrow it to 100-120.
• Additional behaviour: For example, adding jitter, smoothing etc. Is this something to lean into, or something to cover over?

Suggested steps for Dynamics Mirrors

1. Working with the raw data and Data Mirrors you’ve already made, get a feel for the input and expression.
2. Be mindful for how it feels to do something to it. It’s natural to want to describe this in computational terms (temperature, speed, angle etc.). Strive instead for metaphorical and experiential forms of description: intense, precarious, wobbly, curious etc.
3. Pick an experiential term/description/frame to use as a goal.
4. Consider how the output could be used for this goal, deconstructing the implications at the computational level (see the implementation section for more).
5. Try out the simplest possible implementation. Remember that the focus is to maximise opportunity for first-hand experience. Keep iterating until it is as close to the experiential goal as possible.
6. Try a different experiential term, perhaps also mixing up output, or the way output/input is used (eg. if you’ve been using colour a lot, try working with rhythm or shape instead).

Overlaps between Data and Dynamics Mirror

In some of these cases, the Dynamic Mirror and Data Mirror may seem the same. For example, say we have an LED which lights up with a brightness according to how hard we press a button. One might argue it is a Dynamic Mirror in that ‘heavier’ force results in a ‘heavier’ response. One might also argue it’s a Data Mirror, in that the brightness of the LED is tied to the analog reading of a force sensor.

How to sort this out? It’s important to be clear what the goal is.

If the goal is a Data Mirror, we ought to judge the outcome by how well the LED mirrors the character of the input sensor values.

If the goal is a Dynamics Mirror, we ought to judge the outcome by well the dynamics of the LED response matches the feel of pressing the button. It may be good luck that our first attempt at this matches the implementation for a similar Data Mirror.

However, with some reflection, we may start to realise that they are not in fact the same. We might say that tapping a button lightly and quickly ought to have a dim and short reaction in the LED. When hitting it harder, we feel a physical sensation after the touch. A sort of reverberation or aftershock.

We realise then that the LED can’t be controlled directly by a force sensor, we have to decouple them. Rather, we want heavier presses to result in a more sustained response, the LED staying lit longer than the touch itself. This implies a more complicated implementation to better match the dynamics, rather than data.

See also: Implementing Mirrors