Author: Xiaotian Fan

What can physical computing provide/add on to the p5 experience? At least, this is the question for me when trying to devise my final project. It’s true that physicality is supposed to be more engaging, more intuitive, etc. While it is also true that the rich visual response p5 allows can easily overshadow the physical portion of a project. That being said, my mission would now become how to assigned the roles of p5 and physical computing.

Some tug-of-war staged in my mind, and it eventually came to me to stick to p5 as the centerpiece while harnessing physical computing as a means to improve the interactive experience. In a simple word, I’m thinking of leveraging my midterm project with the aid of the physical input—constructing a physical environment, simulating a pilot pod, and transforming the PVE experience into PVP.

From a technical perspective, there may be two approaches to achieving the vision that differ from each other by the number of computers involved in the project. On the one hand, if one computer plus an external screen would be supported by p5, then the physical installation should become easier; while if p5 does not allow it, then two computers may need to be set, and the burden on the physical part to communicate info would drastically increase. At this particular moment I believe it’s time to experiment a bit more with p5 and Arduino at large to find out the right pathway.

Following codes are built upon the bidi serial example

Practice 1: Shifting Ellipse

let rVal = 0;

function setup() {
  createCanvas(640, 480);
  textSize(18);
}

function draw() {
  background(10);

  fill(map(rVal, 0, 1023, 100, 255));

  if (!serialActive) {
    text("Press Space Bar to select Serial Port", 20, 30);
  } else {
    text("Connected", 20, 30);
    
    // Print the current values
    text('rVal = ' + str(rVal), 20, 50);

    ellipse(map(rVal, 150, 600, 0, width), height /2, map(rVal, 150, 600, 50, 200));
  }
}

function keyPressed() {
  if (key == " ") {
    // important to have in order to start the serial connection!!
    setUpSerial();
  }
}

// This function will be called by the web-serial library
// with each new *line* of data. The serial library reads
// the data until the newline and then gives it to us through
// this callback function
function readSerial(data) {
  ////////////////////////////////////
  //READ FROM ARDUINO HERE
  ////////////////////////////////////

  if (data != null) {
    // make sure there is actually a message
    // split the message
    let fromArduino = split(trim(data), ",");
    // if the right length, then proceed
    if (fromArduino.length == 1) {
      // only store values here
      // do everything with those values in the main draw loop
      
      // We take the string we get from Arduino and explicitly
      // convert it to a number by using int()
      // e.g. "103" becomes 103
      rVal = int(fromArduino[0]);
    }

    //////////////////////////////////
    //SEND TO ARDUINO HERE (handshake)
    //////////////////////////////////
    let sendToArduino = 0 + '\n';
    writeSerial(sendToArduino);
  }
}

/* Arduino Code

void setup() {
  // Start serial communication so we can send data
  // over the USB connection to our p5js sketch
  Serial.begin(9600);

  // We'll use the builtin LED as a status output.
  // We can't use the serial monitor since the serial connection is
  // used to communicate to p5js and only one application on the computer
  // can use a serial port at once.
  pinMode(LED_BUILTIN, OUTPUT);

  // start the handshake
  while (Serial.available() <= 0) {
    digitalWrite(LED_BUILTIN, HIGH); // on/blink while waiting for serial data
    Serial.println("0,0"); // send a starting message
    delay(300);            // wait 1/3 second
    digitalWrite(LED_BUILTIN, LOW);
    delay(50);
  }
}

void loop() {
  // wait for data from p5 before doing something
  while (Serial.available()) {
    digitalWrite(LED_BUILTIN, HIGH); // led on while receiving data

    if (Serial.read() == '\n') {
      int sensor = analogRead(A0);
      delay(5);
      Serial.println(sensor);
    }
  }
  digitalWrite(LED_BUILTIN, LOW);
}

*/

Practice 2: Brightness Control

let brightness = 0;
let rVal = 0;

function setup() {
  createCanvas(640, 480);
  textSize(18);
  background(0);
}

function draw() {
  background(map(brightness, 0, 255, 0, 255), 0, 0);

  fill(255);
  if (!serialActive) {
    text("Press 'Space' to connect to Serial Port", 20, 30);
  } else {
    text("Connected to Arduino", 20, 30);
    text('Brightness: ' + brightness, 20, 60);
    text('rVal: ' + rVal, 20, 90);

    // Map mouseX to brightness (0-255)
    brightness = map(mouseX, 0, width, 0, 255);
    brightness = int(constrain(brightness, 0, 255));

    // Display instructions
    text("Move mouse horizontally to change LED brightness", 20, height - 20);
  }
}

function keyPressed() {
  if (key === ' ') {
    setUpSerial();
  }
}

// This function will be called by the web-serial library
// with each new *line* of data. The serial library reads
// the data until the newline and then gives it to us through
// this callback function
function readSerial(data) {
  ////////////////////////////////////
  //READ FROM ARDUINO HERE
  ////////////////////////////////////
  if (data != null) {
    // make sure there is actually a message
    // split the message
    let fromArduino = split(trim(data), ",");
    // if the right length, then proceed
    if (fromArduino.length == 1) {
      // only store values here
      rVal = fromArduino[0];
    }

    //////////////////////////////////
    //SEND TO ARDUINO HERE (handshake)
    //////////////////////////////////
    let sendToArduino = brightness + '\n';
    writeSerial(sendToArduino);
  }
}

/*

// LED Brightness Control via Serial
const int ledPin = 9; 

void setup() {
  // Initialize serial communication at 9600 baud
  Serial.begin(9600);
  
  // Set LED pin as output
  pinMode(ledPin, OUTPUT);
  pinMode(LED_BUILTIN, OUTPUT);
  pinMode(2, OUTPUT);
  
  // Blink them so we can check the wiring
  analogWrite(ledPin, 255);
  delay(200);
  analogWrite(ledPin, 0);

  // start the handshake
  while (Serial.available() <= 0) {
    digitalWrite(LED_BUILTIN, HIGH); // on/blink while waiting for serial data
    Serial.println("0,0"); // send a starting message
    delay(300);            // wait 1/3 second
    digitalWrite(LED_BUILTIN, LOW);
    delay(50);
  }
}

void loop() {
  // Check if data is available on the serial port
  while (Serial.available()) {
    digitalWrite(LED_BUILTIN, HIGH);

    // Read the incoming byte:
    int brightness = Serial.parseInt();
    // Constrain the brightness to be between 0 and 255
    brightness = constrain(brightness, 0, 255);
    if (Serial.read() == '\n') {
      // Set the brightness of the LED
      analogWrite(ledPin, brightness);
      delay(5);
      // Send back the brightness value for confirmation
      Serial.println(brightness);
    } 
  }
  digitalWrite(LED_BUILTIN, LOW);
}

*/

Practice 3: Windy Balls Bouncing

let velocity;
let gravity;
let position;
let acceleration;
let wind;
let drag = 0.99;
let mass = 50;

// for uno connection
let rVal = 0;
let LED = 0; 

function setup() {
  createCanvas(640, 360);
  noFill();
  position = createVector(width/2, 0);
  velocity = createVector(0,0);
  acceleration = createVector(0,0);
  gravity = createVector(0, 0.5*mass);
  wind = createVector(0,0);
}

function draw() {
  background(255);

  fill(10);
  
  if (!serialActive) {
    text("Press S to select Serial Port", 20, 30);
  } else {
    text("Connected", 20, 30);
  
    // Print the current values
    text('rVal = ' + str(rVal), 20, 50);
  }
  
  if (rVal > 0) {
    wind.x += map(constrain(rVal, 200, 600), 200, 600, -0.5, 0.5);
    applyForce(wind);
  }
  
  applyForce(gravity);
  velocity.add(acceleration);
  velocity.mult(drag);
  position.add(velocity);
  acceleration.mult(0);
  ellipse(position.x,position.y,mass,mass);
  if (position.y > height-mass/2) {
      LED = 1;
      velocity.y *= -0.9;  // A little dampening when hitting the bottom
      position.y = height-mass/2;
  } else {
    LED = 0;
  }
}

function applyForce(force){
  // Newton's 2nd law: F = M * A
  // or A = F / M
  let f = p5.Vector.div(force, mass);
  acceleration.add(f);
}

function keyPressed(){
  if (key == "s") {
    // important to have in order to start the serial connection!!
    setUpSerial();
  }

  if (key==' '){
    mass=random(15,80);
    position.y=-mass;
    position.x=width/2;
    acceleration = createVector(0,0);
    velocity.mult(0);
    wind = createVector(0,0);
  }
}

function readSerial(data) {
  ////////////////////////////////////
  //READ FROM ARDUINO HERE
  ////////////////////////////////////

  if (data != null) {
    // make sure there is actually a message
    
    // split the message
    let fromArduino = split(trim(data), ","); 
    
    // if the right length, then proceed
    if (fromArduino.length == 1) {
      // convert it to a number by using int()
      rVal = int(fromArduino[0]);
    }

    //////////////////////////////////
    //SEND TO ARDUINO HERE (handshake)
    //////////////////////////////////
    let sendToArduino = LED+'\n';
    writeSerial(sendToArduino);
  }
}

/*

int ledPin = 9;

void setup() {
  // Start serial communication so we can send data
  // over the USB connection to our p5js sketch
  Serial.begin(9600);

  // We'll use the builtin LED as a status output.
  // We can't use the serial monitor since the serial connection is
  // used to communicate to p5js and only one application on the computer
  // can use a serial port at once.
  pinMode(LED_BUILTIN, OUTPUT);
  pinMode(ledPin, OUTPUT);

  // Blink them so we can check the wiring
  analogWrite(ledPin, 255);
  delay(200);
  analogWrite(ledPin, 0);

  // start the handshake
  while (Serial.available() <= 0) {
    digitalWrite(LED_BUILTIN, HIGH); // on/blink while waiting for serial data
    Serial.println("0,0"); // send a starting message
    delay(300);            // wait 1/3 second
    digitalWrite(LED_BUILTIN, LOW);
    delay(50);
  }
}

void loop() {
  // wait for data from p5 before doing something
  while (Serial.available()) {
    digitalWrite(LED_BUILTIN, HIGH); // led on while receiving data

    int ledState = Serial.parseInt();
    if (Serial.read() == '\n') {
      digitalWrite(ledPin, ledState);
      int sensor = analogRead(A0);
      delay(5);
      Serial.println(sensor);
    }
  }
  digitalWrite(LED_BUILTIN, LOW);
}


*/

Okay, let’s see what we got from this – passage from last century. Again, for me, it’s for sure an extension of our exploration and discussion on ‘balance,’ – but in an extended context.

For sure, whether the examples of eyeglasses, leg splints, iPods, and so on are within the context of disability or not, what intrigued me is how those supposedly pioneering principles suggested at that time are nowadays spread across a much broader scope: What’s particularly striking is how the central tensions – between fashion and discretion, simplicity and universality – have indeed become increasingly relevant beyond disability design. The Eames leg splint case study perfectly exemplifies this: what began as a disability-focused design solution ultimately influenced mainstream furniture design, challenging the traditional ‘trickle-down’ assumption that innovations flow from mainstream to specialized markets. The argument for moving beyond pure functionality or pure aesthetics to find ‘simplicity in concept and simplicity of form’ feels particularly prescient. Sometimes, it’s so easy to dwell in a term that seemingly fits all – yet we all know there is no such case. Therefore, whether we are dealing with balance or any of the included or parallel concepts, maybe the only fit-for-all is to find out what exactly the idea, ideology, or principle we claim to realize, follow, and develop stands for in the very specific case of our own designing.

INTRO

What makes something an instrument? I’d like to borrow a concept from Rehding 2016, Three Music-Theory Lessons: ‘epistemic things,’ things that we use to practice knowledge while themselves are the knowledge in terms of how knowledge is generated. Aside from the extent to which a person can easily make acoustically pleasant sound waves out of an installation, what constitutes an instrument is that itself is an epistemic thing—having connections with and making it feasible to practice our common musical knowledge on while embodying a distinct system that generates/contributes to musical knowledge/practice.

That being said, how we divided our work is basically mapping the two sides (and the two stage of the development) to the two of us—the music and the interface, the backend and the frontend, the soft and the hard, etc. On my side, I had the Arduino and the speaker to start up a very basic synthesizer consisting of two audio oscillators and two control oscillators.

Process

In a nutshell, what I tried to realize is a simple cosine wave oscillator frequency modulated according to the four input parameters that control root frequency: intensity (the extent to which the root signal is modulated to the target frequency), vibrato speed (the rate at which the modulation is automatically carried on), and modulation ratio (the multiple to determine the target frequency from the root).

#include <Mozzi.h>
#include <Oscil.h> // oscillator
#include <tables/cos2048_int8.h> // table for Oscils to play
#include <Smooth.h>
#include <AutoMap.h>

// desired carrier frequency max and min, for AutoMap
const int MIN_CARRIER_FREQ = 22;
const int MAX_CARRIER_FREQ = 440;

// desired intensity max and min, for AutoMap, inverted for reverse dynamics
const int MIN_INTENSITY = 10;
const int MAX_INTENSITY = 1000;

// desired modulation ratio max and min
const int MIN_MODRATIO = 5;
const int MAX_MODRATIO = 2;

// desired mod speed max and min, for AutoMap, note they're inverted for reverse dynamics
const int MIN_MOD_SPEED = 10000;
const int MAX_MOD_SPEED = 1;

AutoMap kMapCarrierFreq(400,700,MIN_CARRIER_FREQ,MAX_CARRIER_FREQ);
AutoMap kMapIntensity(400,700,MIN_INTENSITY,MAX_INTENSITY);
AutoMap kMapModRatio(400,700,MIN_MODRATIO,MAX_MODRATIO);
AutoMap kMapModSpeed(400,700,MIN_MOD_SPEED,MAX_MOD_SPEED);

const int FREQ_PIN = 0;
const int MOD_PIN = 1;
const int RATIO_PIN = 3;
const int SPEED_PIN = 2;

Oscil<COS2048_NUM_CELLS, MOZZI_AUDIO_RATE> aCarrier(COS2048_DATA);
Oscil<COS2048_NUM_CELLS, MOZZI_CONTROL_RATE> kIntensityMod(COS2048_DATA);
Oscil<COS2048_NUM_CELLS, MOZZI_AUDIO_RATE> aModulator(COS2048_DATA);

int mod_ratio; // harmonics
long fm_intensity; // carries control info from updateControl() to updateAudio()

// smoothing for intensity to remove clicks on transitions
float smoothness = 0.95f;
Smooth <long> aSmoothIntensity(smoothness);

void setup(){
  Serial.begin(115200); // set up the Serial output for debugging
  startMozzi();
}

void updateControl(){
  // read the freq
  int freq_value = mozziAnalogRead<10>(FREQ_PIN); // value is 0-1023

  // map the input to carrier frequency
  int carrier_freq = kMapCarrierFreq(freq_value);

  // read the ratio
  int ratio_value = mozziAnalogRead<10>(RATIO_PIN);

  // map the input to ratio
  mod_ratio = kMapModRatio(ratio_value);

  //calculate the modulation frequency to stay in ratio
  int mod_freq = carrier_freq * mod_ratio;
 
  // set the FM oscillator frequencies to the calculated values
  aCarrier.setFreq(carrier_freq);
  aModulator.setFreq(mod_freq);

  // calculate the fm_intensity
  int mod_level= mozziAnalogRead<10>(MOD_PIN); // value is 0-1023
  fm_intensity = ((long)mod_level * (kIntensityMod.next()+128))>>8;

  // use a float here for low frequencies
  int speed_value = mozziAnalogRead<10>(SPEED_PIN);
  float mod_speed = (float)kMapModSpeed(speed_value)/1000;
  kIntensityMod.setFreq(mod_speed);
}

AudioOutput updateAudio(){
  long modulation = aSmoothIntensity.next(fm_intensity) * aModulator.next();
  return MonoOutput::from8Bit(aCarrier.phMod(modulation)); // phMod does the FM
}

void loop(){
  audioHook();
}

THE GLOVE

Zavier here, now it’s my turn! So after testing the circuit and code (huge thanks to Xiaotian for the awesome sound control!), I began working on attaching it to the glove, which was… painful. I first just measured out and positioned things, then I started attaching them with my small transparent tape (which isn’t the ideal way (sowing it would be better), and besides my tape wasn’t strong at all). After asking a friend for help, I got the sensors attached. Ok, the easy part done. Now the troubles begin. You see, I obviously had to connect the flex sensors to the Arduino. I thought I could I just use the female-male wires, but nope! The pins on the flex sensors were too small, so it was far too lose :(. I tried thinking of a few other options, but in the end, I had to do what I was trying to avoid, soldering. To be honest, I didn’t even mind it that much before (past me talking), and thought it would take a few fun minutes, but boy oh boy. I don’t know what it is about these solders (maybe they’re dirty?), but only a very tiny bit of the tip is actually going to melt the solder, so a lot of time was spent just moving and rotating the tip. Also, I shouldn’t have attached the flex sensors already. It was a huge pain to get them soldered. Now admittedly, (probably a large) part of that is because I’ve hardly soldered before, but also (in addition to the tip issue), I was making these 3 point connections (such as connecting the ground of one the flex sensors, to the ground of the adjacent ones), so whenever I tried soldering, it would just release the other 2!

Anyways, after some work, I finally got the flex sensors wired up, and it was finally working. Great! Ok, we’re done… we’re done?…. right?. Haha, nope. I thought it would be a good idea to add neopixels (addressable LED strips) to the gloves too. After testing a strip, I didn’t repeat my mistake, and this time I soldered together the strips first, before attaching them. This went a lot smoother (also thanks to just having some experience doing it for the flex sensors), but it still took sooo long. Unfortunately, since I soldered it first, the connections weren’t the right length 🙂. Luckily, I had expected them not to be precisely correct (and besides the distance between the strips would change a bit as the hand was flexed and relaxed), and so kept it a bit longer, so that the length could be adjusted as needed. This unintentionally also ended up creating a nice pattern 😅.

While it was a lot of work, it definitely made things a LOT cooler, and also provided a way to give some info to the user visually.

 

Final Product

Demo (note: the sound is very distorted in the recording)

Code:

// Configuring Mozzi's options
#include <MozziConfigValues.h>
#define MOZZI_ANALOG_READ_RESOLUTION 10 // Not strictly necessary, as Mozzi will automatically use the default resolution of the hardware (eg. 10 for the Arduino Uno), but they recommend setting it (either here globally, or on each call)

#include <Mozzi.h>
#include <Oscil.h> // oscillator
#include <tables/cos2048_int8.h> // table for Oscils to play
#include <Smooth.h>
#include <AutoMap.h>

#include <FastLED.h>


// Flex sensor stuff

// Define flex sensor pins (these have to be analog)
const int FREQ_SENSOR_PIN = A0;
const int MOD_SENSOR_PIN = A1;
const int SPEED_SENSOR_PIN = A2;
const int RATIO_SENSOR_PIN = A3;

// Smoothening for each pin (was previously using rolling averages)
Smooth<unsigned int> smoothFreq(0.8f);
Smooth<unsigned int> smoothMod(0.5f);
Smooth<unsigned int> smoothSpeed(0.75f);
Smooth<unsigned int> smoothRatio(0.5f);

// Input ranges for flex sensors (will be calibrated)
unsigned int freqInputMin = 1000; // Just FYI, the flex sensors in our setup roughly output in the range of ~ 200 - 650
unsigned int freqInputMax = 0;
unsigned int modInputMin = 1000;
unsigned int modInputMax = 0;
unsigned int speedInputMin = 1000;
unsigned int speedInputMax = 0;
unsigned int ratioInputMin = 1000;
unsigned int ratioInputMax = 0;


// Neopixel (addressable LED strip) stuff

// Define neopixel pins
const int FREQ_NEOPIXEL_PIN = 2;
const int MOD_NEOPIXEL_PIN = 3;
const int SPEED_NEOPIXEL_PIN = 4;
const int RATIO_NEOPIXEL_PIN = 5;

// Number of LEDs in each strip
const int NEOPIXEL_NUM_LEDS = 11;

// Define the array of leds
CRGB freqLEDs[NEOPIXEL_NUM_LEDS];
CRGB modLEDs[NEOPIXEL_NUM_LEDS];
CRGB speedLEDs[NEOPIXEL_NUM_LEDS];
CRGB ratioLEDs[NEOPIXEL_NUM_LEDS];


// Sound stuff

// desired carrier frequency max and min, for AutoMap
const int MIN_CARRIER_FREQ = 22;
const int MAX_CARRIER_FREQ = 440;

// desired intensity max and min, for AutoMap, inverted for reverse dynamics
const int MIN_INTENSITY = 10;
const int MAX_INTENSITY = 1000;

// desired modulation ratio max and min
const int MIN_MOD_RATIO = 5;
const int MAX_MOD_RATIO = 2;

// desired mod speed max and min, for AutoMap, note they're inverted for reverse dynamics
const int MIN_MOD_SPEED = 10000;
const int MAX_MOD_SPEED = 1;

Oscil<COS2048_NUM_CELLS, MOZZI_AUDIO_RATE> aCarrier(COS2048_DATA);
Oscil<COS2048_NUM_CELLS, MOZZI_CONTROL_RATE> kIntensityMod(COS2048_DATA);
Oscil<COS2048_NUM_CELLS, MOZZI_AUDIO_RATE> aModulator(COS2048_DATA);

int mod_ratio; // harmonics
long fm_intensity; // carries control info from updateControl() to updateAudio()

// smoothing for intensity to remove clicks on transitions
float smoothness = 0.95f;
Smooth<long> aSmoothIntensity(smoothness);


void setup(){
  Serial.begin(9600); // set up the Serial output for debugging

  // Set the flex sensor pins
  pinMode( FREQ_SENSOR_PIN, INPUT_PULLUP);
  pinMode(  MOD_SENSOR_PIN, INPUT_PULLUP);
  pinMode(SPEED_SENSOR_PIN, INPUT_PULLUP);
  pinMode(RATIO_SENSOR_PIN, INPUT_PULLUP);

  // Setup the neopixels
	FastLED.addLeds<NEOPIXEL, FREQ_NEOPIXEL_PIN>(freqLEDs, NEOPIXEL_NUM_LEDS);
	FastLED.addLeds<NEOPIXEL, MOD_NEOPIXEL_PIN>(modLEDs, NEOPIXEL_NUM_LEDS);
	FastLED.addLeds<NEOPIXEL, SPEED_NEOPIXEL_PIN>(speedLEDs, NEOPIXEL_NUM_LEDS);
	FastLED.addLeds<NEOPIXEL, RATIO_NEOPIXEL_PIN>(ratioLEDs, NEOPIXEL_NUM_LEDS);
	FastLED.setBrightness(32); // 0 - 255

  // Feed/prime/initialise the smoothing function to get a stable output from the first read (to ensure the calibration isn't messed up). A value of 1630 was chosen by trial and error (divide and conquer), and seems to work best (at least for our setup)
  smoothFreq.next(1630);
  smoothMod.next(1630);
  smoothSpeed.next(1630);
  smoothRatio.next(1630);

  startMozzi();
}


// Basically our actual traditional loop in Mozzi (but still needs to kept reasonably lean and fast)
void updateControl(){

  // Read the smoothened freq
  int freqValue = smoothFreq.next(mozziAnalogRead(FREQ_SENSOR_PIN - 14)); // value is 0-1023, -14 since mozzi just takes a number (eg. 0 instead of A0), and the analog ones are 14 onwards

  // Calibrate the mapping if needed
  if (freqValue < freqInputMin) freqInputMin = freqValue;
  if (freqValue > freqInputMax) freqInputMax = freqValue;

  // Map the input to the carrier frequency
  int carrier_freq = map(freqValue, freqInputMin, freqInputMax, MIN_CARRIER_FREQ, MAX_CARRIER_FREQ);


  // Read the smoothened ratio
  int ratioValue = smoothRatio.next(mozziAnalogRead(RATIO_SENSOR_PIN - 14));

  // Calibrate the mapping if needed
  if (ratioValue < ratioInputMin) ratioInputMin = ratioValue;
  if (ratioValue > ratioInputMax) ratioInputMax = ratioValue;

  // Map the input to the ratio
  mod_ratio = map(ratioValue, ratioInputMin, ratioInputMax, MIN_MOD_RATIO, MAX_MOD_RATIO);


  // calculate the modulation frequency to stay in ratio
  int mod_freq = carrier_freq * mod_ratio;
 
  // set the FM oscillator frequencies to the calculated values
  aCarrier.setFreq(carrier_freq);
  aModulator.setFreq(mod_freq);


  // Read the smoothened mod
  int modValue = smoothMod.next(mozziAnalogRead(MOD_SENSOR_PIN - 14));

  // Calibrate the mapping if needed
  if (modValue < modInputMin) modInputMin = modValue;
  if (modValue > modInputMax) modInputMax = modValue;

  // Calculate the fm_intensity
  fm_intensity = ((long)modValue * (kIntensityMod.next()+128))>>8;


  // Read the smoothened speed
  int speedValue = smoothSpeed.next(mozziAnalogRead(SPEED_SENSOR_PIN - 14));

  // Calibrate the mapping if needed
  if (speedValue < speedInputMin) speedInputMin = speedValue;
  if (speedValue > speedInputMax) speedInputMax = speedValue;

  // use a float here for low frequencies
  float mod_speed = (float)map(speedValue, speedInputMin, speedInputMax, MIN_MOD_SPEED, MAX_MOD_SPEED) / 1000;
  kIntensityMod.setFreq(mod_speed);


  // Set the leds

  FastLED.clear(); // Resets them

  // The frequency controls how many of the LEDs are light up (in a rainbow colour)
  int freqLEDAmount = map(freqValue, freqInputMin, freqInputMax, 0, NEOPIXEL_NUM_LEDS);
  fill_rainbow(&freqLEDs[NEOPIXEL_NUM_LEDS - freqLEDAmount], freqLEDAmount, CRGB::White, 25); // &...LEDs[i] to start lighting from there, allowing us to light them in reverse

  // For the mod, show a meter (blue - deep pink) showing the mix level of the 2 sounds
  int modLEDAmount = map(modValue, modInputMin, modInputMax, 0, NEOPIXEL_NUM_LEDS);
  fill_solid(modLEDs, NEOPIXEL_NUM_LEDS, CRGB::Blue);
  fill_solid(&modLEDs[NEOPIXEL_NUM_LEDS - modLEDAmount], modLEDAmount, CRGB::DeepPink);

  // The speed controls the blinking rate of its LEDs (between 1/2 to 3 seconds per blink cycle)
  int speedLEDBlinkRate = map(speedValue, speedInputMin, speedInputMax, 500, 3000);
  if (millis() % speedLEDBlinkRate < speedLEDBlinkRate/2)
	fill_rainbow(speedLEDs, NEOPIXEL_NUM_LEDS, CRGB::White, 25);

  // The ratio controls the hue of its LEDs
  int ratioLEDHue = map(ratioValue, ratioInputMin, ratioInputMax, 0, 360);
  fill_solid(ratioLEDs, NEOPIXEL_NUM_LEDS, CHSV(ratioLEDHue, 100, 50));
  // We could also blend between 2 colours based on the ratio, pick the one you prefer
  // fract8 ratioLEDFraction = map(ratioValue, ratioInputMin, ratioInputMax, 0, 255);
  // fill_solid(ratioLEDs, NEOPIXEL_NUM_LEDS, blend(CRGB::Blue, CRGB::DeepPink, ratioLEDFraction));

  FastLED.show(); // Shows them
}


// Mozzi's function for getting the sound. Must be as light and quick as possible to ensure the sound buffer is adequently filled
AudioOutput updateAudio() {
  long modulation = aSmoothIntensity.next(fm_intensity) * aModulator.next();
  return MonoOutput::from8Bit(aCarrier.phMod(modulation)); // phMod does the FM
}


// Since we're using Mozzi, we just call its hook
void loop() {
  audioHook();
}

 

Believe it or not, I nearly believed that Magic Ink link would be “super-brief.”

Well, in terms of disillusioning, I guess the readings did a great job. On the other hand, I wasn’t really interested (at least at the beginning) in the topic – yes, it’s obvious from the first paragraph what the reading is up for. And my mere response to that would be, ‘Okay, maybe that’s not a promising vision, but I still want us to achieve it someday.’ However, beyond the ‘rant’ itself, what intrigued me was the idea of ‘the conventional means of interfacing the brain to the world (i.e., the body).’ Essentially, from my perspective, that is my first impulse to get in touch with IM: how are we going to interact (input and output info) as human beings in the future?

I always told people that I don’t like to read—but I’m forced to do so just because it holds (arguably) the most dense info on this planet. That’s in terms of ‘the media’—whatever that delivers information. At least for now, according to the scope of info that we can quantify, text still has its edge. (Honestly, it’s really sad news for me to acknowledge at the beginning – like a couple of years ago – that probably music that is based on audio (2 parameters) and paints based on images (arguably three parameters?) as the art forms I love has their inherent limit to express—even if we haven’t (or maybe already) reached).

On the other hand, what about humans? I mean, what about our bodies? I would say that people who strive to devise new media and convey and people who strive to plunge into our cognitive system are two teams that approach the same theme from two angles. I cannot answer if ‘bypassing’ the body is a good thing or not. But, for now, I would say the body is still a component of what we call ‘human.’

Okay, we should have read these earlier, I guess. Rather than discovering now things (well, there are a few in the physical computing list), I would say that reading these two passages was like reacquainting myself with some of my takeaways from the first half of our course.

‘Shut up’ is a rude phrase, especially when it’s called to the alleged ‘creator’ of a piece – I thought. Then it comes to the question again: “To what extent could we deem to be the creator, and to what extent should the intentionalistic pursuit of the creator be respected?” I have no clear answer to this. But if we hop out of the framework of intentionalism and think of ‘shut up’ as also a part of the ‘creation’ process—as if there is no static ‘art piece’ but only the rating process (borrowed from musicking if you’re curious), then the seeming sacrifice of intentionalism could serve something higher than itself. Philosophical enough, even merely regarding the pragmatic effect that ‘shut up’ could bring us, I believe the amusing moments that happened in our mid-term presentation could speak for themselves, signaling us creators to take another lens and subsequently improve the creation. That is, in a sense, also the creation process, isn’t it?

Anyway, as for the topics/types of physical computing projects listed, obviously, just within our class (or even only within my projects), there are already a lot of ‘overlapping’ ideas. If you ask me if in this particular case I would be bothered by the ‘ingenuity’, the answer – surprising or not – would be a clear NO. My interpretation of this problem would be similar to cover versions of music and the iteratively performed classical music – each and every version/performance contributes to the collective musicking process with its own uniqueness. Even if we are ‘just copying’, there is still nothing to be ashamed of: copying, or more professionally speaking, imitating, is still one of the best ways to learn.

intro

Again, identifying the challenging aspect of the mission seemed the very first step I would take in approaching a new product. This time, while digitally/analog-ly reading/writing can be achieved easily, finding the right connection between the readings and the writings—in terms of both values and functions is what I’d like to focus on. As I found the light sensor we tried in class interesting enough, I came up with this product by combining the light sensors and a servo.

process

Although theoretically, maybe we should have a clear picture of the final product before getting our hands dirty (and I thought I had), sometimes it did take time to distinguish between ‘think of a function’ and ‘think of a product.’ In the first stage of my development, the ‘rotating to follow the light source’ function was already achieved, while the ‘product’ had only the electronics exposed blatantly:

Later on, the very simple concept of a sunflower following the sun finally popped up in my mind. With one piece of cardboard added to the product, although the concept may seem simpler than ‘Dual Light Sensor Servo Control,’ the gist is much more directly conveyed, I believe. On top of that, the additional layer of cardboard actually brought the bonus of normalizing the light sensors physically by shielding out the ambient light:

schematics & illustration

Both of the graphs are drawn and generated with TinkerCAD

Code

The servo rotation is based on the difference between the readings of the two light sensors:

/* 
‘Sunfbot’
Dual Light Sensor Servo Control
This program controls a servo motor based on the difference between two light sensors.
The servo moves to track the stronger light source.

Components:
- 2x LDR (Light Dependent Resistors)
- 2x 10kΩ resistors for LDRs
- 2x 3300Ω resistors for LEDs
- 1x Switch
- 1x 9g Servo
- 1x Blue LED
- 1x Green LED


reference:
https://www.arduino.cc/en/Tutorial/BuiltInExamples/AnalogReadSerial
https://www.arduino.cc/en/Tutorial/LibraryExamples/Sweep
*/

#include <Servo.h>

// Pin definitions
#define SWITCH_PIN 2      // Toggle switch input pin
#define SERVO_PIN 9       // Servo control pin
#define BLUE_LED_PIN 10   // Blue LED pin (standby indicator)
#define GREEN_LED_PIN 11  // Green LED pin (running indicator)
#define SENSOR1_PIN A2    // First light sensor
#define SENSOR2_PIN A3    // Second light sensor

// Constants
#define SENSOR_THRESHOLD 30  // Minimum difference between sensors to trigger movement
#define SERVO_DELAY 30       // Delay between servo movements (ms)
#define SENSOR2_OFFSET 30    // Calibration offset for sensor 2

Servo myservo;  // create servo object
int pos = 90;    // variable to store servo position

void setup() {
  // Initialize serial communication
  Serial.begin(9600);
  
  // Initialize servo
  myservo.attach(SERVO_PIN);
  
  // Configure pins
  pinMode(SWITCH_PIN, INPUT_PULLUP);
  pinMode(BLUE_LED_PIN, OUTPUT);
  pinMode(GREEN_LED_PIN, OUTPUT);
}

void loop() {
  // Read sensors
  int sensor1Value = analogRead(SENSOR1_PIN);
  int sensor2Value = analogRead(SENSOR2_PIN);
  int sensorOffset;

  // Read switch state
  int switchState = digitalRead(SWITCH_PIN);
  
  if (switchState == LOW) {  // System active (switch pressed)
    // Update status LEDs
    digitalWrite(GREEN_LED_PIN, HIGH);
    digitalWrite(BLUE_LED_PIN, LOW);

    // Apply sensor calibration
    sensor2Value -= SENSOR2_OFFSET;
    
    // Check if right sensor is significantly brighter
    if ((sensor2Value - sensor1Value) > SENSOR_THRESHOLD) {
      if (pos < 180) {
        pos++;
        myservo.write(pos);
      }
    } 
    // Check if left sensor is significantly brighter
    else if ((sensor1Value - sensor2Value) > SENSOR_THRESHOLD) {
      if (pos > 0) {
        pos--;
        myservo.write(pos);
      }
    }
    // If difference is below threshold, maintain position
    myservo.write(pos);
    delay(SERVO_DELAY);
    
  } else {  // System in standby (switch released)
    // Update status LEDs
    digitalWrite(GREEN_LED_PIN, LOW);
    digitalWrite(BLUE_LED_PIN, HIGH);
    
    // Return to center position
    myservo.write(90);
  }

  // Debug output
  String message = String(sensor1Value) + " " + 
                  String(sensor2Value) + " " + 
                  String(switchState) + " " + 
                  String(abs(sensor1Value - sensor2Value));
  Serial.println(message);
}

Hindsight

Cardboard Gang YES. While I thought I could use the laser cutter to prepare the parts of this product, it turned out that cardboard allowed the product to be finished on time. It’s still true that laser-cut acrylic may look nicer, but it surely should only be introduced when things are settled.

intro

How tough can designing a switch be? Presumably not much—but it’s the contrary. While the circuit to utilize a switch may be one of the simplest ones in the electronics world, to what extent can that switch ‘make sense’ as well as be creative and ergonomically intuitive? From the distance-triggered switch I rushed in class to a coin-classifier that utilizes the different diameters of different coins, both of these prototypes I made in the course seem too ‘basic’ in terms of being so realistic (aka. boring). At the end of the day, setting off from the concept of ‘using body parts,’ I came up with the idea of a ‘Sleepiness Detector’ that would act as an automatic alarm (visually with LEDs and sonically with a buzzar) when the user (if there is one) closes their eyes.

process

Although the first two prototypes are discarded, I would still give credit to them here as a chronicle:

Still, the second prototype did give me some inspiration about using the conductive fabric to form the later artificial eyelids. While the code below is relatively simple, I would say the most difficult part of this product is to ‘install’ artificial eyelids to my eyes—maybe this is where collaboration was a necessity.

/*
+---------+               +--------+
| Switch  |  eyes         | LED R  |
|         |               |        |
| Terminal|--- Pin 2 ---  | Anode  |--- Pin 9 (Arduino)
|         |               |        |
| Terminal|--- GND        | Cathode|--- GND (through 220Ω resistor)
+---------+               +--------+
                         
                         +--------+
                         | LED G  |
                         |        |
                         | Anode  |--- Pin 10 (Arduino)
                         |        |
                         | Cathode|--- GND (through 220Ω resistor)
                         +--------+
                         
                         +---------+
                         | Buzzer  |
                         |         |
                         | Positive|--- Pin 11 (Arduino)
                         |         |
                         | Negative|--- GND
                         +---------+
*/

#define SWITCH_PIN 2   // Pin connected to the switch
#define RED_LED_PIN 9  // Pin connected to the red LED
#define GREEN_LED_PIN 10 // Pin connected to the green LED
#define BUZZER_PIN 11   // Pin connected to the buzzer

void setup() {
    pinMode(SWITCH_PIN, INPUT_PULLUP); // Set switch pin as input with pull-up resistor
    pinMode(RED_LED_PIN, OUTPUT);       // Set red LED pin as output
    pinMode(GREEN_LED_PIN, OUTPUT);     // Set green LED pin as output
    pinMode(BUZZER_PIN, OUTPUT);        // Set buzzer pin as output
}

void loop() {
    // Read the state of the switch
    int switchState = digitalRead(SWITCH_PIN);

    if (switchState == LOW) { // Switch is ON (active low)
        digitalWrite(RED_LED_PIN, LOW);      // Turn off the red LED
        digitalWrite(GREEN_LED_PIN, HIGH);   // Turn on the green LED
        tone(BUZZER_PIN, 1000);              // Play sound at 1000 Hz
    } else { // Switch is OFF
        digitalWrite(RED_LED_PIN, HIGH);     // Turn on the red LED
        digitalWrite(GREEN_LED_PIN, LOW);    // Turn off the green LED
        noTone(BUZZER_PIN);                   // Turn off the buzzer
    }
}

schematics & illustration

Both of the graphs are generated with TinkerCAD

Product Demo

Hindsight

Obviously, the method I used to install eyelids was not wise enough to replicate easily. If this is actually to be a thing, then there must be some more mature way to detect if eyes are closed.

It’s all about the balance – right?

Aesthetics vs. function, durability vs. lightness, artistic vs. technical—it’s so easy to fall into a binary mindset. To some extent, my intuitive argument would be: ‘Yes, that indeed makes life easier—but in terms of?’ While we humans like clear frameworks and roadmaps to navigate through the complexities, it seems that at the end of the day, despite the urge to simply pick a side (or polarize, in a fancy way), things—in many cases—turned out the most favorable when we took a step down and found the middle ground.

In fact, it seems quite contradictory to me, especially considering Norman’s arguments as a whole: yes, we tend to be hard-headed and pick sides intuitively, and the ‘fact’ seems to praise the balanced, but to perceive that balanced beauty/harmony/coherence or whatever induced, it comes back to our first-hand perception system (or effects in Norman’s words).

Okay, I’ll try to step down from delving into the philosophical rabbit hole. However, maybe more practically, how can these inquiries benefit our—or my—practice? From poetry to music to tennis, I constantly struggle between the fine lines. And now, not surprisingly, but ‘coding’ turned out to be the same. If I am to name a takeaway from this, then although I may not be able to point out a solution to any of the fields at the point or even forever, it must be, again, transforming the mindset:

When we use the term balance, what’s its connotation? If something, two or more, needs to ‘be balanced,’ at least it sounds to me that we are assuming that those things are intrinsically conflicting to some extent. But what if they do not conflict with each other in the first place? I’m not saying that this is the new version of ‘fact’ but suggesting maybe we should try to get rid of that guggling mindset and try as hard as possible to really, really look at what we are dealing with as a whole.

 

 

#####LINK TO THE GAME#####
#####CODE OF THE GAME#####
(Unfortunately my p5 seems down for no reason;
Project is temporarily hosted on GitHub)

intro

First of all, as the game design documentation in my progress report has included the essence of my project at large, I would try to focus more on the improvements and specificities I made in this second stage of developing my NEXT-GEN-SOMATIC-MOTION-SENSING-SPACE-SHOOTING-ACTION game, Motion Ship.

tech and concept DEVELOPMENT

When it comes to the development of the project, I would say that there are two parts to the story: 1. To realize and polish my initial vision; 2. To make decisions in terms of removing elements from the plan or adding flavors to it (e.g., removing the audio level & mouse control to reduce the complexity of commands to only head motion and keyboard inputs).

1. Interactive Experience

As the centerpiece of the game, the realization of the concept of ‘controlling the spaceship with the player’s head motion’ was my primary objective. Although at the end of the first stage, I had achieved the basic mapping relationship between the head position detected by the ML model and the displayed position of the player spaceship in the game, there were still several awkward shortcomings, including:

1. The ship respawns itself every frame in the head position directly instead of moving towards it smoothly. This was later tackled by introducing the smooth-approaching logic I used in my first project.
2. The ship’s motion responsiveness to the head motion was too ‘authentic’, leading to the player’s having to literally move drastically in order to control the ship instead of intuitively directing the ship with slight movements. This was tackled by adding factors of motion sensitivity to the mapping relationship.
3. The ship appeared to be ‘translating’ in space (although in terms of programming, it is), instead of reflecting the aerodynamic behavior of real aircraft. Thus, rotations in all three axes were introduced to simulate such effects.

update(headPos) {
  if (this.toDestroy === false) {
    // Update position based on head movement (-1 to 1 mapped to screen space)
    let targetX = map(headPos.x, -1, 1, -width, width);
    let targetY = map(headPos.y, -1, 1, -height * 1.5, height * 1.5);
    this.x += (targetX - this.x) * 0.15;
    this.y += (targetY - this.y) * 0.15;
    
    // Constrain the postion within the gaming zone (2.87 approx. 3 calculated from triangular perspective: fovy = 0.5, camZ = 800, shipZ = 280)
    this.x = constrain(this.x, -gamingZone.width / 3, gamingZone.width / 3);
    this.y = constrain(this.y, -gamingZone.height / 3, gamingZone.height / 3);
    
    // Update rotation based on head movement
    this.rotationX = map(-headPos.y, -1, 1, -PI / 3, PI / 3);
    this.rotationY = map(headPos.x, -1, 1, -PI / 10, PI / 10);
    this.rotationZ = map(headPos.x, -1, 1, -PI / 1.25, PI / 1.25);
    
    // Tactic engine reset
    if (this.tacticEngineOn === true) {
      let currentTime = millis();
      if (this.model === assets.models.playerShip1) {
        this.health = 100;
      } else {
        this.energy = 100;
      }
      if (currentTime - this.tacticEngineStart > 15000) {
        this.tacticEngineOn = false;
        if (this.model === assets.models.playerShip1) {
          this.health = 100;
        } else {
          this.energy = 100;
        }
      }
    }

2. Gameplay Aspect & UI

One major awkwardness I spotted then was that when the canvas aspect followed the window, the 3D spatial relationships between the objects and the visual distortion tended to be uncontrollable – for example, an enemyship could seem on the laser trajectory of the player when in the distance, but in fact it was an illusion introduced by perspectives. As a result, I devised several mechanisms to smooth out the experience, including:

1. Define a definite gaming zone with constant aspect (1:1) on the window (regardless of whether the window is in vertical or landscape aspects).
2. Trigonometrically calculate and confine the objects in the 3D space in relation to the camera position.
3. Enlarge the collision box & the speed of the lasers fired to reduce difficulty when hitting moving enemies.

On top of that, other improvements besides the gaming zone include allowing enemy ships to launch lasers, incorporating different meteoroid models, displaying pilot logs and other info on the margin out of the gaming zone, displaying laser and health bar within the gaming zone, etc.

3. Visual Effects

To further improve the immersiveness of the gameplay, I made four major changes:

1. Space dust randomly generates and flies towards the player’s ship, creating a sense of speed (compared to the insufficient indication of speed when there were only enemies and obstacles flying slowly towards the player).

   class SpaceDust {
     constructor(maxParticles = 50) {
       this.maxParticles = maxParticles;
       this.particles = [];
       this.spawnRate = 2; // Number of particles to spawn each frame
       this.initParticles();
     }
   
     // Initializes the particles array with empty particles.
     initParticles() {
       for (let i = 0; i < this.maxParticles; i++) {
         this.particles.push(this.createParticle());
       }
     }
   
     /*
     Creates a single dust particle with random properties.
     @returns {Object} A particle with position, velocity, size, and lifespan.
     */
     createParticle() {
       return {
         pos: createVector(random(-gamingZone.width / 2, gamingZone.width / 2), random(-gamingZone.height / 2, gamingZone.height / 2), -random(1000, 1500)),
         vel: createVector(0, 0, random(80, 100)), // random Z speed
         size: random(2, 4),
         lifespan: random(50, 200) // Frames the particle will live
       };
     }
   
     // Updates all particles: moves them forward and resets them if necessary.
     update() {
       for (let i = 0; i < this.maxParticles; i++) {
         let p = this.particles[i];
         p.pos.add(p.vel);
         p.lifespan --;
   
         // If the particle has passed the player or its lifespan ended, reset it
         if (p.pos.z > 300 || p.lifespan <= 0) {
           this.particles[i] = this.createParticle();
         }
       }
     }
   
      // Renders all particles onto the screen.
     render() {
       push();
       // Enable additive blending for a glowing effect
       blendMode(ADD);
       for (let p of this.particles) {
         push();
         translate(p.pos.x, p.pos.y, p.pos.z);
         noStroke();
         fill(255, 255, 255, map(p.lifespan, 0, 200, 50, 255)); // Fade out based on lifespan
         sphere(p.size);
         pop();
       }
       blendMode(BLEND); // Reset to default blending
       pop();
     }
   }

2. Vignette effect in the background to create depth instead of having all the objects floating on a plane.

   loadBackgroundWithVignette(key, path) {
     loadImage(path, (img) => {
       const vignettedImg = this.applyVignette(img);
       this.textures[key] = vignettedImg;
     });
   }
   
   applyVignette(img) {
     // Create a graphics buffer the same size as the image
     let gfx = createGraphics(img.width, img.height);
     gfx.clear();
   
     // Parameters for the vignette
     let centerX = img.width / 2;
     let centerY = img.height / 2;
     let maxDiameter = max(img.width, img.height) * 1.25;
   
     gfx.noFill();
     gfx.background(0, 0, 0, 0); // Ensure transparency
   
     gfx.blendMode(BLEND);
   
     // Draw multiple concentric ellipses to create a radial gradient
     for (let r = maxDiameter / 2; r > 0; r -= 20) {
       // Adjust alpha based on radius
       let alpha = map(r, 0, maxDiameter / 2, 40, 0); // intensity: darkest part = 50, larger the darker
       gfx.noStroke();
       gfx.fill(0, 0, 0, alpha);
       gfx.ellipse(centerX, centerY, r, r);
     }
   
     // Convert gfx (p5.Graphics) to p5.Image
     let vignetteImage = gfx.get();
   
     // Create a copy of the original image to avoid modifying it directly
     let processedImg = img.get();
   
     // Blend the vignette image onto the processed image using MULTIPLY mode
     processedImg.blend(vignetteImage, 0, 0, vignetteImage.width, vignetteImage.height, 0, 0, processedImg.width, processedImg.height, MULTIPLY);
   
     return processedImg;
   }

3. Parallax effect of the background to increase the responsiveness of environment to the player’s motion.

   class Background {
     constructor(texture) {
       this.texture = texture;
       this.xOffset = 0;
       this.yOffset = 0;
       this.playerPreviousX = null;
       this.playerPreviousY = null;
       this.parallaxFactor = 250; // Adjust for parallax strength
     }
   
     update(playerX, playerY) {
       let playerMovementX = playerX - this.playerPreviousX;
       let playerMovementY = playerY - this.playerPreviousY;
       
       // Calculate the background offset
       this.xOffset += playerMovementX * this.parallaxFactor;
       this.yOffset += playerMovementY * this.parallaxFactor;
       
       this.playerPreviousX = playerX;
       this.playerPreviousY = playerY; 
     }
   
     render() {
       push();
       translate(-this.xOffset, -this.yOffset, -5000); // Positioned far in the background
       noStroke();
       texture(this.texture);
       // Render a large plane to cover the background area
       plane(width * 7.5, height * 7.5);
       pop();
     }
   }

4. The windshield (although only frames) around the gaming zone to enhance the sense of an FPP piloting experience.

4. Game Flow

After hearing feedback from several friends, I decided to add an instruction page before entering the gameplay to make life easier for the players.

In addition, I also enabled the player to restart the game immediately instead of having to restart from scratch or reconfigure the game.

5. Storytelling

Last but not least, one of the most illuminating takeaways from developing this project is to recognize and accommodate the gap between a developer’s understanding/assumption and the players’ ‘infinite’ possibilities to approach the product. For example, displaying the variable names on the screen or using them in the instructions seems to be clear enough for me during the development, while a player may not have enough experience or interest to distinguish and follow.

Therefore, I replaced the variable names with terms of more meaning within the space action worldview to create more intuitive guidelines for the player with the aid of visual indications.

SOme words, in hindsight

It is true that there is no ‘perfection’ in terms of finishing a project – at this point, I still have many ideas to add to the game if regarding it as a game to publish or so, including level design, more value balance, more storytelling, enemy and obstacle varieties, bosses, more tactic engines (special skills of each ship), more consistent aesthetics, and so on. On the other hand, I found myself quite satisfied with this current presentation – in terms of me utilizing wheels and knowledge learned in the process, trying to think not only from a developer perspective, and establishing a coherent storytelling through a product, etc. And it made me more excited to get into the physical programming.