We are very used to communicate through physical properties, screens, graphics and images - but sound is often forgotten. For this course we are going to turn that upside down. You are given a [ chose your own color ] cube. You can add what ever sensors and actuators to it but are not allowed to change its appearance (no visual affordances). The goal is that your cube can communicate its function only through sound. A person who has never heard of your project should be able to find out what it can do without any further explanation.

What to do

• Develop a purpose for your cube. 
  • What functionalities/services does it provide? (what is its function?)
  • What kind of processes are going on inside the cube? 
• How should the interaction with your cube feel? Is there an emotional arc?
• Create a sonic moodboard
• Develop multiple scenarios of how the cube could be approached, touched, moved and how it reacts to it. 
  • Proximity
  • Elevation
  • Loudness
  • Brightness
  • Acceleration
  • Orientation
  • ...
• Build a Wizzard-of-Oz setup that allows you to test your ideas
• Validate your concept trough user testing 
  • invite a number of people (one after the other) to try out your cube
  • play the interaction sounds in sync with the test-users actions
  • record the user test (video + audio)
  • ask the users what worked for them and what didn't. How did they feel? (document)
  • analyse the recordings 
  • define lessions learned (what worked, what didn't)
  • improve your concept and your sounds
  • do this iteration as often as possible!
• Plan your functional prototype
  • what kind of sensor-data do you need?
  • what kind of logic do you need to program?
• Start building your functional prototype and keep evaluating your concept and sounds through user tests while you do it! 
• Do the same usertests: review - improve - iterations with your functional prototype

You can use any sound you can find on the internet. If you find sounds that are not in the public domain or free of licence you can use them for the screening in class but have to be really careful when putting it on the web. Self recorded sounds are much appreciated. Dialog zwischen Objekt und Raum.

Wir alle haben uns in den letzten 10 Monaten sehr daran gewöhnt remote in Teams zu arbeiten. Zoom, Teams, Meet, Skype und wie sie alle heissen funktionieren inzwischen alle relativ gut. Dennoch ist die Situation für viele nach wie vor unbefriedigend. Seit Monaten alleine im Zimmerchen zu arbeiten sagt manchen zu, vielen aber auch nicht. Soziale Vereinsamung und unzufriedenstellende Arbeitsbedingungen hinterlassen langsam ihre Spuren. Zudem funktionieren gewisse Dinge einfach nicht wirklich Remote. Virtuelle Apéros oder «ein gemütliches informelles Beisammensein» funktioniert (zumindest für mich) nicht. Eine Diskussion führen fühlt sich anders an, das digitale «Hand heben» (wie es z.B. Meet inzwischen fix im UI verankert hat) sind Lösungsansätze, welche das Potential noch nicht voll ausschöpfen. Wir untersuchen mit dieser Projektarbeit, wie wir diese Situationen über spatial Audio verbessern können. 

In diesem Themenbereich bewegen wir uns in diesem Projekt. Ihr habt die Möglichkeit für euch selbst eine Problemdefinition festzulegen und eigene Ideen und Ansätze zu entwickeln. Folgende Punkte müssen aber berücksichtigt werden. 

• Arbeiten mit spatial Audio entweder mit Kopfhörer und Ambisonic Simulation (präferiert) oder mit einem 4 Channel Speaker Setup vor Ort

Prozess

• Analyse
  • Was genau funktioniert nicht oder fehlt? Was funktioniert gut? Warum? 
    • Eure subjektive Sicht
    • Brainstorming in der Gruppe
    • Befragt auch andere (nicht-Studenten) und überlegt euch, wer welche spezifischen Ansprüche hat
• Problemdefinition (Forschungsfrage)
  • Sucht euch eine spezifische Situation aus und beschreibt das Kern-Problem, welches ihr lösen wollt
• Lösungsansätze
  • Kreativ
  • Inhaltlich
  • Technisch
• Mockup
  • abhängig vom eurer Idee - kann z.B. auch in Form eines kleinen Hörspiels sein
• Test
  • testet eurer Mockup mit mindestens 5 Personen
  • die Tests müssen dokumentiert werden
  • Test analysieren und Findings für nächste Prototypenphase ableiten: Was hat funktioniert, was nicht? 
• Prototype
  • Erstellt einen (zumindest teilweise) funktionalen Prototypen
  • Ihr könnt auch einzelne Funktionen oder nur kleine Teile des Prozesses gesondert als Prototyp bauen. Ist euer Lösungsansatz technisch sehr komplex macht dies durchaus Sinn. 
• Test
  
  • Überarbeitet euer Testsetup und führt weitere tests mit entweder den gleichen oder anderen Personen durch (wenn die gleichen Personen, muss diese Entscheidung begründet werden). 
  • Test analysieren und Findings für nächste Prototypenphase ableiten: Was hat funktioniert, was nicht? 
• Prototype
  • Überarbeitet die Prototypen
  • Funktionsumfang und Zuverlässigkeit des Prototypen erweitern
• Test
• Prototype 
• Test
• Prototype 
• ...
• Dokumentieren
  • 30-60' Video bei dem ihr eure Idee erklärt und die Lösungsansätze vorstellt
  • Blog
• Präsentieren

Face tracking and sending osc:

https://github.com/kylemcdonald/ofxFaceTracker/releases

https://github.com/CreativeInquiry/FaceOSC-Templates