by can.kuytak -

Blog_4 Pygame

4. The First Working PyGame Prototype

The first version that really worked was made with PyGame. It was still simple, but it was the first time the system became interactive in the way I wanted. The GUI sent x and y values for the listener position. These values went into the calculation script, where the relation between source and listener was calculated. Then the resulting parameters were sent to REAPER and the IEM plug-ins.

This was an important moment because the project stopped being only a plan. I could move something in the interface and hear a change in the audio system. Even if the first version was rough, that connection was exciting. It showed that the basic chain was possible: GUI movement, Python calculation, OSC messages, REAPER processing, and spatial output.

At this stage, the interface was not yet the final one. It was more like a proof of concept. But it already contained the essential idea. The listener position mattered. Source distance could be calculated. Direction could be calculated. Values could leave Python and arrive inside the audio engine. That was the first working skeleton of the project.

Technically, this also helped me understand the different roles of the scripts. The GUI was not the model. It was the interface. The calculation part was the direct-sound model or direct-sound calculation script. The OSC sender was the communication layer. REAPER was the audio engine. This separation later became important for explaining the project clearly.

The first PyGame version also made me think more seriously about movement. I did not want the listener to just drag a dot and read numbers. I wanted the interaction to feel a little more embodied. Even though the system is headphone-based, movement is still central to the experience. The listener moves through a virtual source layout and hears changes that relate to position.

This is also where the project started touching game-like thinking. The controller, the movement, and the view direction reminded me of old first-person games. That connection was not planned, but it became part of the development story. It helped me think about how spatial audio tools could feel less like lab software and more like something you can inhabit.

The first PyGame prototype was not polished, but it was the first real success. It proved the system could exist.

by can.kuytak -

Blog_3 First Interface Attempts

3. First Interface Attempts: Pure Data and Max/MSP

My first instinct was to try Pure Data. It felt natural because it is close to sound-design workflows and patch-based thinking. I thought it might be a good place to create a simple interface that sends position values to the audio system. In theory, that made sense. But in practice, I quickly ran into a limitation: I wanted a visual and movement-based interface, and Pure Data did not feel comfortable enough for that.

The problem was not that Pure Data cannot send values or control sound. It can. The problem was the kind of experience I wanted. I wanted the listener to move, see sources, understand room geometry, and feel the relation between position and sound. The visual and animation side became important very early. My Pure Data attempts did not give me that feeling, so I stopped trying to force the GUI into a tool that did not suit the direction anymore.

After that, I tried Max/MSP. Max felt better for visual work and interaction. It gave me more control and felt more flexible than Pure Data for this particular task. I could imagine a more useful interface there. But even with Max, the result did not quite match what I wanted personally. It still felt like I was fighting the environment a little bit. I wanted something that behaved more like a small interactive application than a patch.

This part of the process was a bit frustrating, but it was useful. It showed me what the interface needed to do. It was not enough to have sliders or number boxes. The interface needed to show a room, show sources, allow movement, and later allow custom layouts and presets. It had to be a small spatial tool, not only a control panel.

In my second meeting with my professor, Python came up as a better option. I already had some basic Python knowledge, and the project became a good reason to build on it. This was slightly intimidating, because I had not used Python in this way before. But it also felt like the right challenge. If I could build the interface myself, I could make it behave exactly the way the project needed.

So Pure Data and Max were not failures in the end. They were part of the filtering process. They helped me understand that the core of this prototype needed to be a custom interface and calculation system, not just an audio patch.

by can.kuytak -

Blog_2

2. Learning the Auralisation Idea Through Drawings and Discussion

One of the important turning points was a meeting where my professor explained the auralisation approach in a very practical way. He drew things on paper: source positions, listener position, signal flow, and how the values should move from a visual interface into audio processing. That was educational for me because it turned the project from a vague spatial-audio idea into a system I could actually build.

Before that, I understood the general concept, but not yet the full chain. I knew that I wanted sound to react to movement. I knew that source distance should affect level. I knew that direction should matter. But the system was still blurry. The drawings helped me understand that the project needed clear stages: an interface, a calculation part, OSC communication, REAPER, spatial audio plug-ins, and finally binaural playback.

This also helped me understand why the word “simulation” is dangerous. A full simulation would mean modelling the complete acoustic behaviour of a room. That includes reflections, reverberation, diffraction, occlusion, source directivity and probably much more. My system does not do that. It calculates the direct path between a source and a listener. That is already useful, but it is not the whole room.

So I started to think of the project as a controlled direct-sound auralisation. This means the prototype gives an audible version of a simple physical relationship: where is the source, where is the listener, how far apart are they, what direction is the source, how much should the level decrease, and how late should the sound arrive?

That framing made the project less grand but much stronger. It also made the next semester clearer. If the prototype represents an ideal direct-sound condition, then the real room can later be understood as the thing that adds complexity. The CUBE will add reflections, room response, interference, loudspeaker behaviour and real perception.

In that sense, the drawings were not just technical notes. They changed how I thought about the thesis. Instead of trying to make a huge system that claims too much, I could build something smaller but testable. That was probably one of the most important lessons in the process.

It also changed my confidence. I had something concrete to implement. The project became a set of solvable problems instead of one giant abstract spatial-audio dream.

by can.kuytak -

Blog_1

1. From Physical Sound Superposition to a New Direction

At the beginning, the project had a different shape in my mind. Last semester I was mainly interested in physical sound superposition: real loudspeakers in a room, sine tones playing at close frequencies, and the listener walking through zones where the sound changes. I liked the idea that the room itself could become a kind of instrument. The piece was not only about listening to tones, but about moving through them and discovering how interference, beating and phase relationships appear in space.

That first idea was more installation-based. I imagined loudspeakers placed in a room and the listener moving physically between them. The focus was on the direct experience of sound in space, not on a screen or an interface. This still feels important to me. Even now, after the project has changed, the original interest is still there: movement, sine tones, spatial relationships, and the strange physical feeling that happens when simple sounds interact.

But as the semester continued, the project moved away from being only a physical loudspeaker installation. In meetings with my professor, it became clear that I needed a more controlled research step before going into the real room. If I directly built a physical installation, many things would happen at once: reflections, room modes, loudspeaker differences, directivity, occlusion, and the listener’s own perception. That can be interesting artistically, but it is difficult to study clearly.

This is where the idea of auralisation entered the project. Instead of trying to simulate the full room, the new direction became: build a controlled direct-sound reference first. In this version, I can define source positions, listener position, distance, direction, level and delay. Then later I can compare that controlled version with the physical room.

So the project did not completely abandon the first idea. It changed its method. The original project was about sound interaction in a real space. The current project builds a headphone-based interactive prototype that can later be tested against a real multi-loudspeaker room. I think this change made the project more realistic as a thesis. It still comes from the same curiosity, but it now has a clearer technical and research structure.

The main question also became more careful. I am no longer asking whether I can completely simulate a room. That would be too large and too easy to overclaim. Instead, the current question is closer to this: how can an interactive binaural auralisation help compare ideal direct-sound behaviour with a real multi-loudspeaker room?

That change in wording matters. It gives the project a better foundation. I can say what the system does, but also what it does not do yet.

by can.kuytak -

Physical Sound Layering Blog 3

Can Kuytak/ Blog 3

Intention

The main goal of this project is to bring the layering techniques used in DAWs into a physical room setting. By placing sine tones and low-frequency textures in different corners, the installation lets listeners move around, changing the sounds they hear and how they engage with them. The room itself becomes an active part of the composition through natural acoustic effects like interference, standing waves, and phase interactions. This creates an immersive sound environment where each listener encounters a distinct mix of overlapping sonic layers.

Tasks Fulfilled by the Project

  1. Spatial Sonic Exploration: Demonstrates how sound interacts with architecture, creating zones of reinforcement, cancellation, and perceptually new tones.
  2. Dynamic Interaction Through Movement: Enables the audience to experience continuously changing sound based on their position.
  3. Minimal Material, Complex Perception: Shows how simple sine waves layered spatially produce rich acoustic textures without digital processing.

Main Goals

  1. Design a sonic environment where sine tones interact naturally through room placement.
  2. Reveal acoustic phenomena such as interference patterns, beating frequencies, and standing waves.
  3. Create a movement-sensitive installation where perception changes with listener position.
  4. Illustrate mechanical (acoustic) layering, demonstrating how physical space generates multi-layered sonic experiences.

Subtasks

  1. Frequency and Tone Design: Select sine frequencies and low-frequency textures; test small frequency differences to produce interference and beating.
  2. Speaker Placement and Room Mapping: Determine positions in corners, analyze reflections, and identify zones of natural acoustic layering.
  3. Acoustic Testing and Iteration: Measure how tones interact at different positions; refine frequencies, amplitudes, and placements.
  4. Environmental Refinement: Adjust speaker angles, levels, and minor modulations to optimize layering and spatial phenomena.

Sequence

Frequency selection

Speaker setup

Walk-through testing

Refinement

Final installation.

Methods and Framework Conditions

  • Information Needed: Basics of room acoustics, standing waves, interference, phase behavior, and frequency propagation.
  • Methods: Testing with sine waves, observing position-dependent changes, iterative refinement.
  • Existing Knowledge: Basic knowledge of sonic environment and sound design tools
  • Resources: Speakers, audio interface, tone generator software (DAW, Max/MSP, Pure Data), optional SPL meter.

Mechanical Layering Concept

By placing sine tones in different corners and allowing low-frequency textures near sources, the installation naturally produces physical layering:

  • Standing Waves: Certain frequencies amplify or cancel in specific zones.
  • Interference Patterns: Overlapping sine tones create perceptual beats and shifting sonic surfaces.
  • Spatial Filtering: Listener movement changes the balance between frequencies, producing dynamic layering.
  • Emergent Phenomena: New perceptual tones arise through acoustic interaction.

Unlike digital layering in a DAW, this mechanical layering is generated by the room itself, making each listener’s experience unique and the space an active compositional element.

Timeline Overview

  • Current Semester – Explore: Research acoustic phenomena, test sine tones.
  • Second Semester – Experiment: Build prototype, experiment with frequencies and speaker layout.
  • Third Semester – Product: Final installation, documentation of installation, prepare presentation.

Questions for Exploration

  • Which sine-tone interactions (beating, interference, modulation) create the strongest spatial presence?
  • How can modulation be used without losing the tone’s fundamental purity?
  • Which listener paths produce the most distinct dynamic layering experiences?
  • Which frequency combinations create the clearest spatial effects?