After much trial, error and great frustration, I finally
designed a Random Algorithm, which I hope will work with the Arduino card. In
theory this simple patch should be able to simply link with the card, and will
randomly send power to the individual parts of the orchestra. Once the
Algorithm is activated (by the main switch) it continuously sends out bang
messages via the loadbang object, whilst, the number of bang messages sent are
controlled by the random object. The random object with an argument (number) of
600 sends out a random number between 0 and 599 to the integer (whole number)
box below. This random number is then fed into the right inlet of the metro
object. This argument populates the metro, which then dictates how frequent a
bang is sent to the button object below. The bang message travels through the
button and reaches the random object below. This random object has an argument
of 6. This means a number between 0 and 5 is then produced and sent to the
integer box below. However, you will notice that there is an object between the
random object and the integer object. This +1 objects adds a 1 to the outputted
number. Thus changing the random outputted number range from 0 to 5, to 1 – 6,
in order to replicate the function of a die.
Initially, I will work with 6 outputs, which I intend to
gradually increase as the project and my programming skills move forward. In
this image example, you will see that the number 5 appears in the final integer
object box. The box is then connected to 6 sel objects, which will be attached
to the Arduino input/outputs. Each time a number is (rolled) generated a bang
message is sent to the sel object and the selected outlet should be powered. The
frequency of the outputted numbers can be increased or decreased by adjusting
the 1st random objects argument. The higher the number the more
often the outputted number will be produced.
Again, as I am new to MaxMSP (Jitter) I will be using this
week to research, experiment, play around and recreate basic video patches. I
have been using and working through all of the MaxMSP (Jitter) tutorials in
order to get to grips with this aspect of program (the video side), and to see
what is achievable. Again, I am not planning to create my Jitter video patches
from scratch, as this will take a great deal of prior knowledge of the program
and time. Instead, I will be working with and reworking existing Jitter
patches. In addition, I have been using the following tutorials –
to again recreate the patches featured in these videos. I have found
that Jitter is far more difficult to use that the audio side of MaxMSP, and
fear that this will take both a lot more learning and time to create my desired
outcome. Digital Video: I
aim to take the digital video tests that were created in experiment 8 and feed
them through Jitter. I will aim to rework the audio patch (I have yet to
create) into a video format. I intend to be able to load the pre-glitched
digital videos into my reworked Jitter patch, which will add further simple
glitch-like effects. These outputted videos will then be outputted through the random
patch (again, which is yet to be created), which will randomly control the
output. The randomly selected digital visual output will then be projected via
a digital projector, and will be grouped with all the other visual outputs of
the Glitch Orchestra.
Rather than this
being an experimental stage of my project, I am instead using this week to
research, explore and learn as much as I can about the coding program MaxMSP. I
intend to incorporate this piece of software into the final performance of my
glitch orchestra. I intend MaxMSP to work in the following ways:
MaxMSP &
Arduino: I will be using a number of electrical devices (TVs, Video Players, 2
x Projectors, CD players, Tape Players, Video Game Consoles), which will make
up the instruments, sections and core components of my Glitch Orchestra. I do
not want all of these devices to play at the same time, and aim for them to
switch off and on randomly via the mains switch. After some initial research, I
found that one possible way of achieving this would be to hook the mains of the
various devices to an Arduino device, which is linked to MaxMSP (running on my
mac). Then, via my mac I intend to control the mains of the attached devices
with a simple randomized patch. Whist in theory this sounds achievable and
relatively simple to execute, this is an entirely new program language that I
have never used before. So, in order to get achieve my dersired results, I have
started with the vary basics of MaxMSP, and have been using the following
tutorials -
To build basic
audio patches. Whilst this is an extremely slow learning process, I am making
some steady progress and have managed to recreate some of the patches that are
featured in the videos, and have started to work my way through the in-house
MaxMSP (audio) tutorials, in order to learn all of the objects and their
functionality. As this software is completely new to me, and this is the first
time I have used a coding program of this kind, I have decided to keep my
patches as simple as possible. I aim to recreate and edit pre-made patches in
order to use them for my desired purposes. I think working from scratch will be
too much to achieve in such a short amount of time. Fortunately, I have a friend
who has used the program before, who will be guiding me through my patch design
and coding process. Glitch Audio: In addition to the random patch
that will be working with the devices, I aim to run the pre-glitched audio
(from experiment 7) into MaxMSP and through another basic patch that will
glitch the audio clips further within the program. This audio will again be
randomly outputted (using another version of the random patch) via two speakers
and will feature as part of the digital audio section of the orchestra.
This technique is again based
on the glitch art technique and used the same basic approach to code editing
and file manipulation. The video files (.mov) are opened as text/edit files,
which transfers the digital video into code. The code can then be edited and
manipulated via cut, copy and paste techniques. I was careful to ensure that
the top and bottom of the code remained, but all attempts of code manipulation
via this technique failed. I tried to get around this by opening the file into
Final Cut Pro and exporting this as a .mov file, but this didn’t work. I
repeated this in Adobe Premiere Pro, and again I was unsuccessful. I went back
to the beginning and tried manipulating a tiny section of the code, saving it,
and reopening it as a .mov file. I found the even the smallest interruption in
the code made the file unreadable. I research this online, but found no
possible way of making this technique work with video files, as any
manipulation caused the video to instantly become unreadable.
Via my research I came across
a video gitching program called youglitch and fed my video into the program.
The software comes with various presets that can be changed in order to create
a glitch-like output. Whilst this was a short cut, I found that the outputs the
program created were amazing and decided to use this instead of my original
code-based technique.
(add videos)
I wanted to try another technique that I had
seen online here - that datamoshes two videos
together, simply by laying one video file on top of the other. This results in
a moshing of the two videos along with the audio to create a new glitched
audio/visual output. This is created by mixing the I and P frames together.
Using the AVIDEMUX software allows you to change the frames (I and P). Here you
can manipulate the frames of each video (changing I frames to P frames, and
vice versa), which results in the overlapping output effect. This technique was
extremely effective, creating a variety of unique glitch-like results.
I will be incorporating both
techniques together and will be using them within visual part of my glitch
orchestra. These will be fed into MaxMSP (Jitter) and they will receive further
effects before they are outputted via the digital projector. I was surprised at
how much the sound output was manipulated during this technique, and have
decided to incorporate the sounds, as the results are simply too interested to
ignore. Again, these will be fed into MaxMSP (audio) and will be further
glitched and replayed via speakers.
Video Degradation
This technique works by
manipulating the analogue format of VHS by continually recording onto the same
tape over and over again. Using a combined portable TV/Video player and a VHS
camera I recorded onto the Video tape ten times in order to achieve a wearing
of the tape – video degradation. By copying from one tape to another over and
over again caused the tape to wear and eventually to image begins to fade,
distort and glitch. Whilst this approach was time consuming, it was extremely
easy to set up and execute (even though it required a number of wires). The
only issue was getting the analogue video onto a digital format. I found that I
didn’t have the required equipment to transfer the VHS to digital, and instead
decided to improvise by recording the VHS screen via a digital recording
source, in order to create a new digital version. Initially, I was worried that
this would affect the quality, but as the whole point of the experiment is to
create a faded and worn version of the original, it didn’t really matter. Both
the sounds and the visuals were equally affected by this approach, which was
certainly a bonus. It wasn’t until the 4th recording that the video
began to fully deteriorate. I was careful to ensure that I didn’t record over
and over again, as I was worried that the tape would eventually snap under the
constant strain.
This is certainly a technique
that I intend to use in my final project. Instead of transferring the video to
digital, I intend to keep the VHS in its original format, and will instead play
it the recorded tape on the unit I used during the recording process. My only
concern is that looping the tape and playing it as part of the glitch orchestra
may cause the tape to snap. This is something that I will need to test, as
playback should not place as much strain on the tape as the recording process.
These experiments again
follow the basic practice used for glitch art images. The audio file is
transferred into a text/edit file, which creates a coded version of the audio
file. Again, large sections of the code can be manipulated by cutting, copying
and pasting them around the file. For this I was again careful to not cut the
beginning, end or too much code at once to ensure that I wasn’t pushing to file
to its limit and making it unplayable. The code it then transferred back into
an audio file and played. I also employed data moshing into my audio file
experimentation, using the same technique, but adding to sets of code together
in order to create a new moshed version of the two original tracks. Again, this
process was relatively quick and easy to execute. The only issue I encountered
was the reworked files would not play in iTunes. I found a way around this by
importing the files into Logic Pro and then exporting them as MP3s. Once I had
resaved the files they the played back via iTunes was then possible.
Whilst in Logic Pro, I decided
to try an original technique. I started by loading a song into Logic, and began
to cut, copy and paste within the program. I chose random sections to edit at a
micro level. Cutting out nanoseconds of audio. Some of which I deleted, moved
around or replicated. Whilst this produced interesting results, I decided to
manipulate the sounds even further by adding a Bitcrusher effect, which changed
the bit rate. I added reverb to round out the sound and ended up creating an
entirely new technique and sound that was extremely effective and glitch-like. The
broken (cut and deleted) code caused a unique effect as Logic generated and
replaced these portions with a white noise-like sound. The replacement noise
varied in both length and volume, depending on how much code was missing. I
really enjoyed this experiment. As I had full control over the file, I could
manipulate the sounds to create a desired sound/output.
I will be using both techniques
in the glitch orchestra, as results were perfectly glitched. The initial
technique created outputs that I could not predict, but the second technique
was easier to manipulate. I think both techniques can be used alongside one
another, and again will be fed into MaxMSP and further glitched.
During my research I discovered an entirely new scene, and a
collective of artists who create both static and moving Glitch art visuals, on
and off-line. Just like Glitch audio works, there are again two different
approaches to this artistic form – natural Glitch and Glitch-like. Artists will
either work with naturally occurring Glitches and errors, whilst others will
force the Glitch, using techniques such as databending, datamoshing, and
circuitbending.
In order to create my desired aesthetic I would need to
force the Glitch, instead of working with naturally occurring errors. I found
that one technique in particular not only created a variety of easily
achievable Glitch-like aesthetics, but it was also an approach that could be
used to pre-Glitch images. Thus creating greater distortion, and further
removing the original meaning and context of each users original works. I was
drawn to this technique, as during the code editing process you have no idea
how the code changes will affect the image outcome. The interruption in the
original code disrupts the image, and the new file is the computers
reinterpretation of the original, as it tries to read and overcome the broken
coding.
For this experiment I took a
number of the record covers (used in other experiments) and glitched the
original image via varying forms of code manipulation. In order to achieve the
glitch image outputs I opened each of the images as text/edit files. In this
format I cut, copied and pasted large sections of the code, deleting some and
rearranging large sections. For some of these images I also employed the
technique of data moshing. For this two images are opened as code and the
copied and pasted code is mixed together to create new moshed version of the
original images. The manipulated file is then saved and reopened as an image
(jpeg).
These techniques are
relatively quick to execute. The more code that is cut and moved the more
glitched the image becomes. There were a few times during the experimentation
of this technique that I glitched the images too much and the files became
unreadable. I found that leaving a large section of code at the beginning and
at the end of the file made it much easier for the file to be read. Removing
huge chunks of code also made it much harder for the code to be read. This
involved a lot of trial and error and allowed me to test the limitations of
this approach. There are limits to forces glitch techniques and manipulating
the code too much pushes the files to their limits.
The new glitched and moshed
images become distorted versions of the originals. It is often easy to spot
within the images where the code has been cut, which results in blank spots and
pixilation. I found this technique to be extremely successfully and I was very
pleased with the images I was able to create. I am currently unsure how these
images will be used in the final orchestra, but I intend to feed them into
MaxMSP in order to manipulate them further, and to project them digitally.
I aim to use this technique
to manipulate both digital audio and video files with the aim of creating
similar outputs.
I knew that the
tapes editing of audio cassettes would be the most time consuming part of the
entire experiment process, and as a result decided to only edit two tapes.
Tape 1: I started
by carefully pulling the tape out of the cassette, and cut a large section of
the tape away. I then cut a small piece of clear tape (around 1-2cm in length)
and taped the two ends together, ensuring that the tape did not twist in the
process. I repeated this process over and over, randomly cutting out varying
amounts of tape, whilst trying to vary the distance between the joins. This
process was extremely intricate and very time consuming. It took almost two
hours to complete the entire tape. On play back I notices that I had left large
portions of tape untouched, allowing the tape to play the original audio. As
soon as the head reached a piece of tape that had been taped together the audio
would either speed up or slow, creating an interesting whirling effect to the
audio. Whilst the playback was extremely successful, and the technique create
some interesting and unusual audio outputs, I feel that the output could have
been improved by a great frequency of joins, and leaving less tape in-between
the joins.
Tape 2: Having
tested out tape 1, I decide to cut the second tape more often, leaving smaller
amounts of tape in-between the original tape. I believed that this would
improve the glitch output, and would result in a unique sound. Again, this
technique took around two hours. Whilst my technique had certainly improved, I
was cutting more, and as a result creating more joins. I tried to play the
finished cassette, but there were some issues with playback. It would seem that
the increased amounts of clear tape made it difficult for the head to read it,
resulting in the tape getting stuck. Whilst I assumed that the addition of more
tape and cut would improve the glitch, it instead pushed the format and player
to its limits, making it difficult for the tape to be played and heard.
In order to
incorporate this technique into the orchestra, I will need some further
testing. I think it is possible to find a happy medium, where the original is
still heavily glitched and still playable. My only concern is this technique is
extremely time consuming.
