## Swish the sound! / Documentation, Process

A week ago, we had our first experience matching the gyroscope’s movement with the amplification of 4 different speakers – one at each corner of the room.

Here is the previous patch I did, which matched the gyroscope’s pointed direction (top right, bottom right, top left, bottom left), to triggering the speakers in the room, corresponding to their location. For e.g., point top right will trigger the top right speaker. When triggered, the speaker will switch on, when not triggered, the sound from that particular speaker will switch wholly off.

Comments from the ground mentioned that perhaps, utilising the volume instead of directly switching the said speaker on/off will allow for a more ‘flow-y’ effect when switching to and fro different speakers. At current, the speakers were discrete: individually separate and distinct.

In addition, the randomising effect of coloured rectangle was indeed distracting. Below is a sneak peek into how it looked like:

One perplexing issue with the (x,y) values was that it was not stable enough, such that the distinction between the third and fourth speaker was not clear enough. Hence, switching between speakers may not be accurate enough for 2 corners.

Perhaps, the curve followed a log curve, instead of a linear function, hence by simply isolating particular sections of the x or y section and extrapolating it with relation to the speakers remain inaccurate.

From here, I decided on trying to covert the log curve into a linear curve, by utilising angles. I used this equation:

‘If tanθ = b/a, then θ = tan^-1(b/a)’

b being the side of the triangle opposite the angle, and a being the side of the triangle gating the side of the unknown angle. However, I fixed the starting ‘corner’/tip of the unknown angle at a given point in x, so one is able to differentiate between angles among all 4 quadrants.

Meanwhile, please refer to the below patch:

I used ‘atan’ to find the angle in radian, after which I converted it back to degrees by multiplying it by 57.2958. Hence, by ‘split’, I tried to match each angle to the ‘gain’, or the volume of each soundtrack. I also attempted to put in 4 different soundtracks to correspond with the 4 speakers (which is also easier to identify which speakers were playing), but ultimately decided to simply stick to 1 soundtrack. Each sound however, was individually recorded from real-life.

However, the angles, while calculated correctly, still tended to jump around, making the change in volume for all speakers jittery. Hence, for recording purposes, I decided to first stick to my initial patch where each speaker was turned on individually, but will continue troubleshooting the angles at a later date. Potential reasons for this jump include: the extrapolation of the angles were too small/huge, hence it was too jittery? Else, it could be that the ‘boundaries’ for the graph was too huge/small, hence the change in angles were too steep/quick.

As for my graphics, I decided to play with jit.gl.gridshape, to create 3D shapes. My intention was to have a sphere pivoting in 3D space. However, in playing around with the z-axis, it was difficult to specifically alter the x,y coordinates to move the z-axis. Hence, I decided to focus on the 2D visualisation of the sphere instead. Initially, it worked perfectly, with the sphere moving in the direction of the gyroscope. Despite my initial success, an unknown error cropped up the next day, and I could not get the sphere to change its position. I also played around with jit.gl.lua, lua being a scripting language which could be input into max msp. I wanted to use the x,y coordinates to replace mouse click, which activated the graphics within the jit.window, but was unable to figure out the mouse click function, which seemed to differ from the mouseclick from jit.lcd.

Therefore, I decided to stick to what I did initially: use jit.lcd to draw a moving rectangle. I would instead fix the perimeters and colour of the rectangle this time round, so that the graphics would not be too flashy.

## “Music Instrument” [the Tun-tun]: Final Product / Assignment 2

Depicted above is the final prototype of the tun-tun.

Functions are as stated (from top-down):

1. Tapping top of head – triggers a beat once
2. Pulling of left ear – controls the volume, and triggers the melody once
3. Pulling out/pressing hard on tip of tongue – triggers a voice on repeat, pull it out again to switch it off
4. Slide the “voice box” up and down – change the pitch of the sound effect

All sounds are recorded in real-life; however, they do not sound melodious when mixed together. New sounds can be input(ed) to replace the current sounds.

Physically speaking, the product stands at my chest-level.

Max MSP patch as depicted below:

See it in action:

## “Music Instrument” [the Tun-tun]: Prototype / Assignment 2

Image of tun tun taken from here

Does it not remind you of a tun-tun (pig-stick used by the Iban people in Borneo/Malaysia to lure pigs into traps)?

Much physical resemblance between the sketch draft and the actual object; yet inspiration was not drawn from the tun tun. Sole commonality remains their names.

My project, aptly named “Tuntun”, features a sphere-shaped human-like head, where controls are placed around the head, eg. mouth, top of head, ears, to mimic a human making sound with his own facial features.

Below shall show a sketch of the areas with sensors:

At current, the ‘head’ is not placed in the order order and position. Further improvements in the patch are left to be desired.

The patch is currently incomplete, but here is a quick insight into some parts of it:

I used Gizmo~, Buffer~, Groove~ in replacement of playlist. Certain tweaks are required – for instance, the song abruptly stops playing when the trigger switches the toggle off. I am trying to include a timer, or delay, to allow for the entire soundtrack to play before it switches off.