To make the physical installation we’ve sent off for a few internet purchases

1. A Mega Arduino (https://goo.gl/zAESHC)

The Mega Arduino was a little expensive in Maplin

We found and bought a much cheaper one on Amazon.

2. A Mega Sheild for the Arduino (http://goo.gl/WR9X0E)

It acts like a breadboard.

3. 2 x 10 metres of 8 core Alarm Cable (https://goo.gl/eImwEK)

4. The Twister Mat! (https://goo.gl/nPcE6s)

5. Jump leads and resistors (as long as possible and 1m, as detailed on the sensor PDF)

 

 

Today we measured the length of the wires needed to allow each spot on the Twister mat to be connected to a piezo sensor.

When measuring the length of the wires we also considered that the Arduino cannot be directly next to the Twister mat as there may be a risk of participants falling on it. Therefore, the wires were extended a significant distance away from the mat as shown in the picture below on the left.

During our initial measuring session (as documented in the above two videos) we discussed how each of the sensors would make its way back to the Arduino. The following videos document the process of picking the best method.

Below are our initial ideas for the wire layouts, although these are not the layouts being used, they were trial and error and eventually led to the most efficient method. We originally thought having 12 wires splitting off to 2 spots each would be the most effective but then learnt that there was some 6 core cable available at the university that we could use. This then meant that we could use this for each wire to split off to 3 spots on the mat.

However, we were unsure of how much cable was available, so we plan to buy our own cable and have each cable split off to 4 spots on the mat. This would save cable and is visually and technically less confusing to integrate, cut and solder. The following is a detailed diagram of the best method we have come up with, it incorporates only 6 wires, each with 8 separate wires inside of them. This means that each wire can accommodate 4 piezo sensors.

We decided to run the wire through the middle of two spots so we could use a total of 6 wires. Each wire will be able to reach four spots, two on the left and two on the right.

The six wire lengths ended up measuring:

• 2x 152cm cable for the small wires connected to the first four spots.
• 2x 198.5 cm cable for the medium wires connected to the second four spots.
• 2x 245cm cable for the large wires connected to the back four spots.

Finally we measured the perimeter of the Twister Mat, it measured 117cm by 174cm.

The small, medium and large wires in their respective positions can be seen in the picture below.

Below shows an example of the marking made to signify where the wire lining needs to be cut later on in the process, it needs to be cut at this point since wires will need to be spread 29cm on each side to reach the spots on both sides of the wire, allowing the inner wires to spread both ways. This marking was made 20cm from the end of the wire, the remaining length to the centre of each spot will be made up by the 8cm piezo wire.

 

Below is an example of the notes taken to figure out the correct length of each wire with some breathing room. Breathing room was vital in case we managed to incorrectly measure one or more results, this way there was no need to worry about whether the wires may or may not reach.

 

 

 

In aiding both ourselves and anyone who uses our programmed patch in future, we have simply used panel objects and changed the colours of them, before putting them behind the code of their respective colours. For example, as you can see from the screenshot below, the tempo randomiser code has a red background (because the tempo spot on the mat will be at the top of the red column of spots). Likewise, the key randomiser code has a blue background, the effects randomiser has a yellow background and the mute randomiser has a green background. As with the tempo, this is because they will all be at the top of their respective colour columns on the mat. We considered it important for our Max and Ableton projects to harmonise with each other as well as visually harmonise to how the mat will be laid out for the installation.

The screenshot below shows each of the loop triggers (all 20/24) that have also been colour coded. Finally, many of the patch chords have been segmented, meaning that the patch is easier to look at, as it doesn’t have wires spiralling all over the place that would otherwise resemble a spaghetti junction!

Throughout the programming process we’ve only managed to actually trigger the loops that we have set up in Ableton Live a couple times from Maxmsp. We’ve almost always managed to midi map the loops but when we’ve banged it in Maxmsp, the loops haven’t triggered. This had made us sceptical about the reliability of the ‘ctlouts’ and midi communication between the 2 softwares, but this didn’t appear to be where the problem lied.

While fiddling around today with a number (integer) object in Maxmsp, we found that the number 64 triggers things, and then any number below that will trigger it off (63 – 0). We only want to trigger them, so a message with the number 64 in it has been added to every instance of code that is assigned to Ableton’s clip slots. This is yet another trial and error finding that has been central to this process, that we weren’t able to find on the cycling74 forums or from any other external help.

The idea with having one of the spots on the mat triggering one of the samples to mute is to create an arrangement aspect of the composition that someone is making. Songs often have parts coming in and out and new sections can be made with the addition or subtraction of parts. As we are already building up loops (through addition) the mute randomiser mutes loops to make new sections (through subtraction).

In terms of midi mapping, we originally wanted the 1 of the 4 ‘track stop’ buttons to be activated to stop a loop on a track, but for some reason it didn’t seem to be possible to midi map in order to mute all of the tracks individually. Principally, however, this would have been too sudden for the loops to stop. Typically in songs, loops don’t suddenly stop, they fade in and out in some way to give the track an evolving nature. Daniel discussed the issue in this video below:

That’s where we tried to influence something different. We wanted the loops to fade out and in. We tried coding this, as seen below.

So this code ramps the volume out and in, but ideally we’d want the volume of a clip to fade out, stay at no volume for a while, before fading back in. Just like instruments fade out for tension or focus and then come back in later. We then simplified the code and used a delay loop to stop the loops from fading back in so quickly.

This code was then duplicated 4 times for the 4 tracks we would be randomly muting, this time including drums, as it is effective to take the drums out, making the other instruments appear more rhythmical. This was then connected to the typical code used for the previous effects that randomises and only bangs each one once, with no repeat bangs.

A range of effects were included in an Ableton audio effect rack. These included:

• Reverb
• Ping Pong Delay
• Bitcrusher
• High Pass Filter
• Grain Delay

The effect rack is shown below. It features blue chains that include effects and then chains that include no effects to act as a clean signal for the overall sound. The chain selector was mapped to a dial and then midi mapped so that it could be control by Max MSP. The small orange chain selector dictates whether the signal is being effected or not. In the screenshot below it is hovering over a clean signal. We included fades in and outs with each of the fades between the clean signal and the effected signal so that it was a smooth-sounding transition every time.

The code below features the same ramping code that the tempo had. This ramps the chain selector of the Ableton audio effect rack.

The two videos below shown a demonstration of the random effects button in use.

The key randomiser was made simply. As shown below, we coded a path to randomise between 12 semitones, or 6 whole tones (-6 to  6 on a Ableton Live dial or G to E in musical terms). A higher transposition range than this would have sounded bad. Songs usually don’t make huge tonal jumps when they key change.

 

One issue with this however, is that it will sometimes select the same key. The ‘one bang’ code that we had made before will need to be integrated to prevent this. Below is a video which demonstrates the key change.

We then needed to find a way to transpose all of the clips from the 3 tracks besides drums (as drums are unmelodic instruments so don’t require key change). Ableton Live doesn’t have a global transposition function. The issue is explained in the following video.

We found a way around this by making a Max4Live instrument. As we used this, this is the only effect of the 4 effects that will be made that won’t require Midi mapping with Ableton. The screenshot below is of what is in the external max patch, controlling Ableton. The udpsend sends the signal to the Max4Live instrument.

The image below shows the coding that is embedded in a Max4Live instrument that globally transposes the pitch of the clips. This is included on each of the 3 tracks.

 

The code below shows the core objects, messages and other items that will form the foundations of our 4 effects buttons. The cycle and random objects mean that banging the sequence will cycle between as many possibilities as we program in, for example, randomly cycling between 4 effects.

We quickly noted down what each of the 4 buttons should do (besides tempo as this has already been done), as you can see in the screenshot below.

We also decided to put a gate in the subpatch [p comparison]. As the screenshot below shows, we originally had the coding coming straight from the sliders. [p comparison] neatens thing up, and is where the signal of the piezo sensors is being sent to. We used a gate because…

We also considered the ‘speedlin’ and ‘change’ objects to slow down the rate at which the sequences would bang, but never used these in the end. It’s good we had multiple options for tackling the same problem, just in case!

 

 

After the brief risk assessment undertaken for the presentation (as seen below) we needed to provide a more detailed and specific one for the installation date.

A more in-depth risk assessment needs to be constructed for the project realisation.

The first image shows basic details of the event such as the activity itself, location, time and the people involved. It also shows the authorisation from the unit lecturer.

 

The second image the final risk assessment authorisation from the unit lecturer.

The third and fourth images showcase the risk assessment that was undertaken for the installation.

The final image is the acknowledgement of the risk assessment by all group members. This was signed by all group members and kept on our persons during the installation day so that it could be presented upon request.