Monday, October 6, 2008

Virtual DJ

by Rong Ma

Overview in brief

The project is named as Virtual DJ, namely, our group intends to bring fresh experience to the people for trying out DJ activities. Typical DJ actions include "mixing" and "scratching", which generally manipulates the music track that is been played. In our example, we use color recognition as interaction method. The program been created is to capture color movements within a given space then generates various types of music sample loops. In this case a web cam is been used as a capture tool for the movement. We then introduced some specially marked gloves, with different colors on each fingertip. These colors are the key to the manipulation of the music. With a combination of these elements, users can easily perform actions as if they are real DJs.



Design Motivation

Our initial goal is to design a simple interface with easy to execute operations to recieve satisfying feedback. We first came across with the idea of using Wii controller as an input device, but as same decisions has been applied with many other project ideas, we abandoned this thought and stick with hand gesture and movements, as it is indeed very simple to initiate. Not only because it is directly percieved through the senses, but also resembles the actions of a real DJ. We want to stick true to the concept, so the decision had risen to the surface at the end: pure and simple hand actions only. Despite limitations and other issues, we decided to include "scratching" and "mixing" in this particular installation.

Related and Influential works

During the brainstorming process, we came across with some cool ideas related to manipulation of music, such as video game controller and DJ style music, we later decided to combine these together to form a more understandable and unique object. We discovered that the idea has already been created by someone else which uses the Nintendo Wii controller to achieve DJ actions. Although it is quite similar to some of the existing video game ideas such as Dance Dance Revolution and Guitar Hero, both use simulations of real life tools to perform actions of the actual activity. As for the Wii controller, it does not resemble anything related to the actual DJ movements, so we didn't choose this idea and approached from a more intuitive view.


Technical Method

We used Max/MSP as the programming tool, together with some jitter patches for performing various actions. The program is been run on a Vista installed PC, rather than a typical Mac, but the actions are all there as for the compatibility is no different.

Web Cam is using to capture the movement of the color markers within the given space. With different positions input different data, the program needs to recognize all the changes and initialize actions at the same time. In the final stage we decided to use 4 types of colors, and thus for the operator to see through the changes clearly, 4 visual screens were embeded using jitter patchs, each screen recognize one specific color.



As for the scratching part, another jitter patch is been applied for manipulating the basic looping sample. By apply the x and y axis into a radial style marker, the program controlls the playback speed from slow to fast. The camera captures the movement of the red color markeron the right hand, the radial marker analyse the angles and send the data though a bucket in order to manipulate the playback speed.


The other patches are used to play additional sample loops, as for the three different colors on the other hand. The jitter patch used is to detect the color appearance on the camera, once the color appeared, a sample is playing once, while if color has appeared multiple times, the sample also will play multiple times by the appearance. The groove patch is used to controll the playback length of each track.




User Experience/Usability Considerations

We intended to let the installation speak for itself, as it is simple from inside out. The interaction interface is very simple, we used a wooden box painted black with a clear perspex stick onto the top, where the users can perform actions on. Inside there's the camera for capturing the hand movements. Although sometimes the appearance did affect people's desire, we somehow managed to deliver the installation in an artistic way, that is, to include a poster. As I am taking care with the production of the poster, the result come out quite satisfactory.

At first we didn't quite have an clear outline for what we need to achieve and accomplish, we decided to take it the simple way: think of the basics, make sure everything is working and then adding extra features. We wishes to include also disc panning and volumne controll, but those can not be executed due to time concerns, we also have to simplify the remaining possibilities to the minimum.

As for the final result, it recieved plenty of possitive feedbacks. Most comment on the creativity and the ideas, we were very happy that our initial goal has achieved. But some users seem to be concerned about the operation process of the installation, we however need to instruct people each time they play for getting the best result.

Final Thoughts
The installation had some problems, such as the color recognition and scratching speed issues. But the exhibition was successful. I am greatly appreciated. I've learned a lot during this course such as intensive teamwork and time management. It is a great experience.
I wish thank Sam and Kirsty for putting up the entire course and the final exhibition. Also my group mates Serge and Rhys, I am very happy to been working with you guys and it is been a wonderful experience throughout the past few days. I want to thank all the other participants and people who took part in this course and exhibition. This success wouldn't be possible without you. : )
References
Audio
WiiJ
Max

Virtual DJ – Documentation by Rhys Griffiths

Brief overview description

The Interactive Sound Studio project created by Serge Viranian, Rong Ma and Myself is a DJ simulation installation titled ‘Virtual DJ’. ‘Virtual DJ’ attempts to create a ‘DJ-ing’ experience for users through its ability to modify and manipulate techno music through actions such as ‘Mixing’ and ‘Scratching’.

Gloves worn by the user have various colours on the fingertips which are tracked by a webcam encased inside a three sided box with a clear Perspex top.

The data collected from the spatial movement of these colour tipped fingers is then used in the installations program, created in Max/MSP, to carry out various operations.

Here is a picture of the installation.

Design motivation

In the early stages of the course, our team initially had similar ideas to create an installation which dealt with the control of music - ‘DJ-ing’ came to mind.

In real life, DJs use their hands to control and modify music. DJ’s use their hands to manipulate vinyl records to create ‘scratching’ noises. They also press buttons and turn knobs to create various sound effects and modify the music. We figured that the hands would be the best type of controller.

Related and influential works

Whilst researching and looking for inspiration, we found numerous related compositions which utilized the Nintendo Wii’s ‘Wii remote’ - ‘Wii J DJ’, ‘Wii Conductor Hero’ and the ‘Wii Loop Machine’ to name a few.

With the success of Video Game titles such as Guitar Hero, in which users use a controller with the appearance similar to that of a real guitar, it could be assumed that users feel immersed and truly stimulated when using controllers resembling their real counterpart.

After discovering the abovementioned compositions, and with the knowledge that many of our peers would be using ‘Wii remotes’ in their projects, we decided that we would rather try to use something else as our major controller.

As we decided on the concept of ‘DJ-ing’ and because our research showed us that people liked to use a simulation of the real thing, we decided that the ‘Wii remote’ was not suitable for this purpose and that the use of spatial movements of the hand on would be better.

Technical method

The encased webcam was used to detect movement data of the coloured markers on the white gloves. Once detected, the data was used by the program created in Max/MSP.

This picture is a snapshot of the program used in the installation which was created in Max/MSP. The webcam tracks the colours on the fingertips of the gloves worn by the user and sends the data to the appropriate box - one box deals with red colours, another with blue, another with green and another with yellow.

These boxes are made up of more codes and operations. The output of these codes and operations is sent to the audio output which is in the bottom left of the picture.

This snapshot shows the process of the ‘scratching’. The data of the spatial movement of the red colours on the right hand glove is taken, and turned into an angle, as can be seen on the left hand side of the picture. This angle data then determines the playback speed of the main looping track.

This was slightly problematic because at some point the angle inverts its values making very high or low playback speeds very difficult to perform.

This snapshot is of the process of playing additional sound loops, as a result of movements of the blue, yellow and green colours on the left hand glove. If colour is detected, the trigger will change its value to true and play the sound. At the top of the picture, the sound files used in the program are being loaded.

User experience / Usability considerations

We wanted to create an experience for the user in which they felt they were being a DJ. We also wanted to create a unique and interesting interface which all sorts of people could use and appreciate.

As the installation intentionally did not have clearly outlined instructions, our goal was to create an experience where the user would be able to take the information they were receiving (the sound output) and then conclude what their movements and actions were affecting.

This worked quite well in most cases, but some users which spent little time using the installation did not completely understand what they had just experienced.

DJ’s mix and manipulate music and try to keep rhythm. Throughout the course, it became apparent that our initial proposal would be too difficult to achieve within the given time frame. We had to leave out panning, volume and tone controls and simplify the other operations.

Therefore, the main challenge and focus of the installation became trying to mix the sounds together in rhythm and for the music to continually flow – as a true DJ would attempt to do.

Resources & References

  • Computer Hardware

ú Laptop

ú High quality headphones

ú Webcam

ú Computer speakers

  • Computer Software

ú Max/MSP with CG Jitter Patch

ú Sound Track Pro

ú Audacity

  • The Box

ú Wood: roughly 3 50cm x 30cm pieces

ú 4mm thick Perspex top

ú Portable fluorescent light

ú Semi-gloss black spray paint

ú Screws

ú Silicone glue

ú Tools and machines from University Workshop

Conclusion

Our installation was well received at the Interactive Sound Studio Exhibition. Users commented that the installation was fun and that they had not used anything like it before. We learn valuable skills in programming, time management and presentation and also learned a lot about sound and how to use it effectively.

FINAL REPORT ON VIRTUAL CONDUCTOR: M. Khalil

PROJECT OVERVIEW

Virtual Conductor was established to control a musical arrangement in real time much the same way as a conductor controls an orchestra. A musical piece is heard and the conductor has control over overall tempo, overall dynamics, as well as individual dynamic enhancement of the four instrument sections (horns, woodwinds and strings, percussion and the solo violin. This was done using a Wii remote was programmed through max/msp.

All the members of our group were involved in all the processes in order to perfect this project. We decided that we should all be in charge of one major aspect of then assignment.
Stephen: Head programmer, Nick: Head of documentation and research, Michael: Head of Audio and pictures.
We collated all our parts together to create an immersive and enjoyable experience for the user of our system.

RELATED AND INFLUENTIAL WORKS

Our idea was conceived because all members of the team had
musical backgrounds. The main works that influenced this idea was
Guitar hero @ guitarhero.com/, and Wii Music @
http://en.wikipedia.org/wiki/Wii_Music and on
e3.nintendo.com/wii/wiimusic/index.html.
Our project turned out quite similar to the Wii Music work, and this
Is exactly what we hoped for.

DESIGN MOTIVATION

Our intent was to provide the user with an immersive but enjoyable experience, they could use over and over again. —The main motivation for this project is that we all have musical back grounds and wanted to control music using gestures in a similar way to which a conductor controls an orchestra.
I personally felt that we successfully achieved this, given the positive reaction of users on the presentation night.



TECHNICAL METHOD

We wanted the user to simulate what a conductor of an orchestra does instinctually. For this we decided that the use of the wiimote and Nun-chuk expansion would be a suitable interface for these purposes. It works by the wiimote controlling the playback speed of pre-recorded orchestral tracks and the Nun-chuk attachment controlling the volume.
The aka.wiimote patch was used for mapping of the wiiremote
To execute this we used the IRCAM software supervp.play~ patch to control the playback speed changes, with limiting the minimum and maximum speeds reachable, while pitch and envelope correction maintained the original pitch and envelope. The nun-chuk joystick is used to increase the dynamics of one of four musical sections. The C and Z button controls the master volume of playback, up and down.

The simplicity in the interface is designed that a person with no musical back ground can come wave their hand to get a varying tempo and use there other hand to adjust volume levels. This I believe is achieved efficiently for the user as there is not many button presses involved for the user.

The interface is also defined that the two parameters that the user will control are laid out one in each hand.

The music was composed with usability of the interface in mind. Knowing that tempo and dynamics were our main controls, I composed the piece so that it builds in intensity and power from beginning to end. This enables the operator to instinctually feel, when something is to be louder or softer, or speed up. The song goes for three minutes and has 4 major sections to it. The 16 or 32 bar sections enable the user to easily manipulate the song, as it is easy to perceive an oncoming change even if you are not familiar with the song.

The music was composed in my studio in Pro Tools. 90% of the sounds came from an orchestral sampler program called EWQLSO GOLD. This was used because of its lifelike and “Hollywood movie” typed sound qualities. This was this taken to be mixed using Izotope Ozone 2.
I also recorded an electric violin in the final dramatic section. I felt like the piece was perfect for our Virtual Conductor example due to its intensity and room for dynamic and tempo articulation. I received very positive feedback on this from almost all the people who came to use our system on the night.

USER EXPERIENCE AND USABILITY CONSIDERATIONS

The user will be a conductor in charge of directing the flow of a piece of music using two Wiimotes as batons.
One hand will be triggering musical sections (strings, horns, woodwind, brass), and the other hand will be manipulating variables such as sustain, dynamics and expression.

It was easy for users to understand and use our system but like anything else it was difficult to master at first attempt. This would make it a great game ( Wii music).
In our earlier reports we made it clear that an instinctual and easy system of mapping must be implemented for ease of use and practicality, I believe we achieved this.
Every person enjoyed using this device especially us, who mastered conducting the song. It was quite addictive and was not too embarrassing waving your hands around.


The user really got the feel of interacting as a conductor in our system. It should not be too embarrassing for a user to move their arms around, as it will be enjoyable to hear the variations in the audio samples in sympathy to the users motions.

One of the main difficulties the user faced is co-ordinating both hands simultaneously for the best possible result. This was exactly what we predicted, but this is another challenge that would make this a good starting basis for a computer game.
Our goal would be for a user to have an immersive and fun experience through manipulating a musical arrangement.


FINAL THOUGHTS

After seeing our final project on show at the presentation night we were quite pleased with the final result. All but one of our major ideas were implemented.
We initially wanted to have additional controls over the 4 sections, especially sustain and reverb. This would have greatly enhanced the experience but was unable to be implemented due to the system crashing. It was something to do with supervp patch lagging the system. In fact I even had to bounce down the individual musical sections as mono, because having 4 stereo tracks was overloading the system too.
To make this a commercial computer style game some sort of graphical representation of what was going on would be seen on the screen, this was definitely out of our league within the time given.
One criticism of our project is that there was only one song. In a game there would be at least a dozen or so songs. Once people played and mastered the song some asked if there was another they could play. Even though this was the case, for this instance it would have been impossible to produce many quality songs in the time given.


Resources

Mac Book Pro- Running of applications

Max 5 demo version – programming

Wiimote – Conductors baton Nun-

chuk attachment – dynamic adjustment

Khalil Sound Production Studio – Various equipment for music production

References

www.cycling74.com

www.guitarhero.com

http://en.wikipedia.org/wiki/Wii_Music

www.e3.nintendo.com/wii/wiimusic/index.html.

www.iamas.ac.jp/~aka/maxwww.ircam.fr




sonic hockey

PROJECT OVERVIEW
This project was based on the idea of air hockey game. Basically, we wanted to create sound during play, and have the movement of the puck to control the sound. The real air hockey table uses air to minimise the friction, and our table not. Therefore, we somewhat used this as part of the creation; we tried to reflect the roughness of the table in the sound created. We also wanted to have another sound played when the puck hit the goal area, and for this to happen, we used contact microphone that picked up the vibration of the puck. We selected a few sound files and have it played randomly.

DESIGN MOTIVATION

Our motivation was to create an audio interface or installation that was suitable for everyone. We had a few different ideas before we decided to pursue the idea of an audio game installation. We thought that by having a game based installation, it would be easier for people to interact, and perhaps a little less intimidating for those who have no knowledge in music.
We believed that sonic hockey was a good idea because there’s no special knowledge required, exciting, and allowed you to have an interaction with not only the interface, but also with another person and of course, sound.

INFLUENTIAL WORKS

The main influence was the real air hockey table. We also looked at a game called sonic pong, a game that required the user to make a noise into the microphone to move the bat. So this is basically the opposite of what we’re trying to do. This game has sound as the input and whilst ours have sound as output.

INTENDED USER EXPERIENCE
The sonic hockey is a two-player game. The game play is similar with the air hockey, you will need to gain control of the hockey puck and try to beat your opponent by trying to score goal. The difference with sonic hockey is that it will also produce sound during play. The ideal is for the players to have long rallies and discover the variety of sound changes during play and to experiment and simply have fun with it. It’s a fun and light game for everyone to enjoy and have a play with.

USABILITY CONSIDERATION
The process of building the sonic hockey is quite tricky. In general people will start comparing it with the functionality of the air hockey table. This, for example, raised a few critical questions like how to reduce the friction and the smoothness of the surface. We had the option of getting a fairly priced second hand air hockey table, which could have made things a lot easier. However, we decided not to because in a way we’re trying to create something that is quite different and thought that it would be challenging for us to actually make something from scratch. One of the things that we had to consider was, would this custom made table interfere with the way people play, and we understood that it will not have the same effect as the air hockey game, and our solution was to somewhat use the table “flaw” as part of the creation. Using a “scratchy” or “heavy” sound effect to match the way the puck’s moving around the table. Technically, having the puck not moving so quickly, it helped the camera to track it a little better.

DESIGN PROCESS AND DEVELOPMENT
Firstly, we started off with some rough sketches, mapping out the best way to build the table, which includes the position of the goal area, camera stand or holder, and the border of the table.
Basically, we are using a pre-existing table and we added a few additional attributes to make this table functional.

Before building the actual table, we did a few material tests to see which one works best. We decided to use timber as our main material because it was available for us and it’s inexpensive. For the boundary or the barrier we’re using guitar strap because it has the best bounce. The strap was stretched across an additional wooden frame, which was screwed to the bottom of the table.

The goal area was a basic square shaped box attached to each end of the table. The box had holes on each side. One small hole on the upper area of the box for the puck to goes in, and the other was on the lower part (on the other side) for the player to pick it up. We’re leaving the other half side of the box covered so that we had a place to attach the contact mic onto. And also to minimise the possibility of the puck from going all over the place when it entered the goal area.

The camera box was made out of four pieces of timber “sewed” together with plastic string. This box was used to cover the actual stand, which is a circle shaped timber with two holes on it. One was for the cable and the other one for the camera lens to see through.
At first we wanted to have the camera dangling from the ceiling but assured that it was not very safe for the camera. Therefore, we decided to sit the camera on Perspex that was placed on top of two pillars on the ceiling, forming a bridge-like holder.

With the puck itself, we’re using a standard air hockey puck and attached a laminex sheet on the bottom part for smoothing and a colour label on the top part for the colour tracking.
After we did a few tests we could actually hear a very loud noise caused by the collision of the puck and the bat. Therefore, we decided to wrap some rubber bands around the bat to minimise it.








TECHNICAL METHOD

Originally we wanted to use a bluetooth mouse inside a custom-made hockey puck and wii remotes for the goal area. We didn’t go with this idea because we thought it would be difficult to play this game when you have a quite heavy puck and the mouse wouldn’t work that well. We were also having a few difficulties finding a way to trigger the button of the wii remote so that the puck will always hit the button when it enters the goal area.

The two key methods we ended up using were colour tracking and contact Mic. The Colour tracking was used to track the location of the puck and the Mic was used to detect when a goal was scored.

With the colour tracking, we placed a mini DV camera on top of the table. The camera was connected to a laptop running Max/MSP. Basically, the camera picked up the colour of the puck and run it through the program. For this we’re using the “jit.qt.grab”. After the colour was locked in, the”jit.findbounds” object was used to track the x and y position of the puck. We applied a sound file to the x coordinate. The sound then played in different speed depending on the movement of the puck.

The contact microphone was secretly placed inside the goal area. It basically picked up the vibration of the object surrounding (as the input) and Max/msp played a sound as the output.
The problem was, it was very difficult to find the right value. So it was either too sensitive or the opposite. Despite of the unpredictable result, the random sound played added extra fun to the game.





CONCLUSION

The process of making this project was incredibly interesting and enjoyable. Not only I learned a lot about audio but also about how to build something from scratch. So it was such a great experience considering I was not really familiar with the area.
I personally feel satisfied with the result and it was great to see people were having fun with it.

RESOURCES
http://www.milmoe.com/artprojects/sonicpong/sonicpong.htm
http://cycling74.com/twiki/bin/view/ResourceGuide/InterestingWork










The Cranky Bear - Robin Mukerjee













Overview

The Cranky Bear changed a lot from its initial conception. At first we wanted the bear to really be just an object used to plainly just manipulate a sound or a song. We decided that we wanted the teddy bear to have a character that would respond to you when you picked up the teddy bear and held it in different ways.

We set out to create a series of different dialogues and sounds that would be triggered when used. When the bear would be lying down flat on its back it would snore over a lullaby inspired song. When the bear was sitting still the bear would rant and speak randomly as if nobody was listen. When the bear was picked he would speak to you but as the dialogue was created, not take any notice of what you were saying. If you were to shake the bear it would make the sound of the of being moved back and fourth. Eventually if you shook it hard enough the bear would get angry and ask to be put down on the table. When the user was holding the bear it could tell it to “relax” or use the word “sleep” as to make the bear ask to be put back down so it could go to sleep.

The Bears character was intended to be cute yet very rude and irritable if it was annoyed.

Related and Influential Works
The Cranky Bear was influenced by other interactive toys that are on the market today. Fundamentally of these toys is the Tickle Me Elmo doll made by Tyco that was introduced onto the American market in 1996. The doll when squeezed (or “tickled”) would laugh hysterically and also shake. The interactive elements of these toys were very successful and subsequently made these toys some of the most successful of their kind.







Tickle Me Elmo








Design Motivation
We wanted to make something which was intended to be used by adults. The bear was initially going to be “The Haunted Bear” in which we wanted the bear to give the user a scary and creepy experience but it was changed to add a more comical side to the toy. We wanted to compromise the child-like nature of the toy by making the bear aggressive and angry. The bear also was to represent a character that would be amusing and relatable to the user.

Technical Method
The audio was recorded by using a Pro Tools Mbox 2 setup. To give the bear a childlike voice we pitch-shifted the original voice up by 8 semitones. Altogether about 50 minutes of dialogue was recorded, the majority of the being for when the bear is sitting and “ranting” to itself, yet the sheer size of these audio files proved a problem when putting them into MaxMSP. The song that was created for the piece was done by simply looping a mini children’s guitar with a keyboard playing a melody. To read the bears motion we used the motion-sensors of a Nintendo Wii remote that was put inside the bear which was then read by the akawii remote MaxMSP patch. We created a patch that would read the X, Y and Z axis of the movement of the bear, each time a specific movement of the Wii remote would change this would trigger another patch which would play a sound. We used the aka listen MaxMSP patch for voice recognition. When a certain word was said this would trigger the another sound within the bear.

User Experience/Usability Considerations
We wanted the user in the end to have a playful and enjoyable use of the bear, and in general the majority of people who used it were impressed and amused by the bear angry talking. Unfortunately bear did not work as well as we had planned and specific instructions were made in order to tell the user how to use it. The loose positioning of the Wii remote inside the bear made the beat unable to read the proper signals that it needed to trigger the sounds we wanted. The bear when picked would talk a little bit but not much. People need to be told to shake the bear in order to make the bear make the shaking noise and eventually get angry. The voice recognition did not work at the exhibition because of background noise that was in the room which was really unfortunate being what I felt, one of the most impressive elements of the bear. With more time and fine tuning and would have been good really get the logistics of the movement of the bear right, with the amount of audio that we had in MaxMSP only a small percentile was actually triggered at the exhibition.






MaxMSP which would detect the movement of bear when shaken






















MaxMSP patch which would detect the voice

















Conclusion
The few hours before the start of the exhibition I was not really happy with the final product. The way we had designed the bear to work was simply not working. But people in general (if they weren’t offended) were amused and impressed with bear which in change gave me piece of mind that we had made a successful exhibit. With more time it would have been really great to fine-tune the motion sensor and voice recognition parts of the bear as to make how we intended.





Resources
Interactive-sound.blogspot.com
http://www.tyco.com/
www.cycling74.com
Interactive Narrative Final Report

version written by Michael Moretti


Overview

Our plan form the beginning was to prove our game design skills, by addressing and overcoming the constraints to make a working, functional, and immersive game. Then the idea came to make a sound only game experience using the Wii remote. So we designed a game, and a story that could be played without any visual aids. This game was title Interactive Narrative. The initial idea for the story was also to make it non-linear. Meaning the story does not just simply play through in a straight line, it can branch off depending on how the player reacts to it. The game needed to include instructions on how to use the Wii remote to do certain actions. The player of this game was also blindfolded, this was intended to add to the experience by taking away all visual distractions, and aiding them in the use of their imagination to create their own environment. In the end the completed game included the tutorial, and first mission, which when played lasted between ten and twenty minutes.

Related and Influential Works

Our influence came from any game on the Wii. The use of the Wii remote to control a character and/or any other aspects of the game. Some well known favourite Wii games include; Zelda: Twilight Princess, Wi Sports, Super Smash Bros, Mario and Sonic at the Olympic Games, and many more. Outside of the mainstream influences was the Virtual Barbershop. An experience made in the form of sound design, that recreated a scene in a barbershop getting a haircut, the way it was designed makes it feel almost real. Which showed us that sound can be extremely immersive when used correctly.

Design Motivation

Our primary design motivation came from Myles and myself being aspiring game designers. We both agreed that a true game designer can use what they are given, and work within constraints to produce a potentially successful game. So we took this on board, and sat down, went through all the constraints, and eventually came up with this game. The initial idea had us both very excited, and the challenge of pulling it off kept us motivated. We also knew that if this was successful that this game would make a great addition to our portfolios, and aid our quest to become game designers. What also motivated the design was the use of the Wii remote. Since we had access to the Wii remote, which is already a game controller, we found more inspiration. Since the wii remote is based off movement it can be used without being looked at, which supported our idea.

Technical Method

Myles was the lead programmer, but i was always close by to lend a hand. We used primarily Max/MSP to put the game together, but with the help of javascript. The javascript was used to do all the nitty gritty decisions, such as take the wii remote inputs, and determine an outcome depending on actions, which was achieved using multiple 'if' statements. Then in Max/MSP we would playback the sounds, and layout the linear function of the story and its scenes, or chapters. The use of the aka.wiiremote helped a lot, otherwise the wii input values would not have been attainable. Each chapter was very similar in set up, the basic set up of each chapter was:

The wii input was taken from a subpatcher, which received the wii values from aka.wiiremote

A switch was used to turn on or off certain wii input subpatches. If all of them were left on, the story looped backwards.

The wii input values were sent into a javascript file which determined what output to send for each action, or wii value.

Then out from the javascript were the sound files that played in response the player actions.

Then the last patch was just to play sound or dialogue that continued the story.

User Experience

When playing the Interactive Narrative, a player becomes immersed in the created world. The use of sounds creates an environment that the player, since blindfolded, and forced to sue their imagination, become fully immersed in. This world becomes their world, at least while they are playing. Also adding to this experience is the Wii remote, since the player actually has to make the actions themselves, rather than just press buttons like on an ordinary game control, they again feel more immersed. And since we were using the Wii remote, which can be used without needing to know the whereabouts of many buttons, it allowed us to blindfold the player, so they didn't have any distractions.

Recognitions

I'd like to personally thank the two members of my team. Myles, who i have always worked well with, we make a great team. He has great design ideas, and awesome programming skills with which this project would not have been possible. And James, who joined our group after the initial designs were made, and contributed some incredible sound design, which would have been a tremendous down fall of our game otherwise. his great work really made the game immersive. Also thanks to Kirsty and Sam for their help and teaching. When it came to programming issues Sam was always happy to help.

Recources

-Max/MSP

-Macbook Pro

-Macintosh Desktop

-Wii remote

Virtual DJ - Serge Viranian




Brief overview


Virtual DJ is an interactive colour recognition interface where the user has control over the speed of a looped track enabling them to "scratch" the track and play various samples with the use of specially coloured gloves.


Virtual DJ is designed with the intent of being a simple and playful music interface with little to no learning curve. The user wearing white gloves with 4 different coloured fingertips (red, green, blue and yellow) waves their hands over the cam placed under a clear top box.




Influential Works


The main influence was derived from WiiJaying which is an emerging trend in performance DJing it uses MAX and Wii controllers and other professional mixing software to both DJ with live and pre-programmed tracks. This interface is more involved and by no means meant for non-professionals which lead us to develop our simple interface which did not rely on any particular controllers.


Design Motivation


We all wanted to design a musical interface that was easy to manipulate on the fly and therefore opted for a virtual DJ set we decided to move away from Wii controllers or any controllers for that matter and to stick to basic hand gestures for a more seamless and intuitive interface.


The design of the physical interface was meant to be as simple as possible so we developed an open ended box which would house the colour tracking web cam all users pretty much knew to just wave their fingertips over the web cam without being instructed.


The MAX interface was designed to be as clear as possible and included a visual screen for each colour. All patched were neatly aligned into sub patches which helped immensely when the program crashed or reset as it helped in booting then patch as quickly as possible.




Technical Method


Using Max and Jitter patches we modified and programmed the following:

  • jit.dx.grab to initialise the web cam we also used the web cams settings to modify the brightness, white balance and colour intensity this proved to take the longest to calibrate as lighting differed at different hours of the day.
  • four jit.findbounds patches in which we entered the 4 colours(yellow, red, blue and green) the exact RGB colours were determined using a sukha on the main web cam viewer. red was used for scratching the other three colours were used to initialise the sample loops.
  • The jit.findbounds for the samples had a togedge each for when the- colours appear only.
  • jit.matrix was used to display the colours on 4 different web cam previewers.
  • the red jit.findbounds was then connected to a cartopol and poltocar to coverts x and y coordinates into radial angles
  • the angles where then plugged through a bucket and multiplied by a constant so as to keep the speed in between -2 and 2 with 1 being the normal speed.
  • The data being transferred was also gated as to go back to normal speed when the coulours weren't appearing
  • All the colours including the processed red were then patched through a groove to output the selected track and samples as well as their lengths.




All that was needed as hardware was a USB headset for audio output and a simple web cam for visual input as well as back light and laptop to run the whole system.



User Experience/Usability Considerations

By trying to make it as intuitive as possible using hand gestures that DJs would use on a normal turntable we reduced the learning curve considerably. The setup was pretty much self explanatory : put headsets and gloves on and wave fingertips or "scratch" away on top of camera to get various sound effects. Nothing to it...

We tried to make the interface as plain and simple as possible but still ended up needing to instruct people in terms of positioning and interaction. The people who spent more than a minute or two on the program started getting the hang of it. When we later pasted instructions next to the DJ box things became a lot clearer for the users. So no matter how simple we may think the interaction is a little instructions never hurt.


Conclusion

All in all it was a great learning experience and given more time I'm sure the project would have been more elaborate and richer in terms of both music quality and interactive elements. Big thanks to Kirsty, Sam, Rhys and Rong was great working with you all.

Resources/References

software:
Max 5.0
Audacity
Reason
hardware:
dell xps M1530 laptop
plantronics dsp 500 headset
logitech webcam
Fluoro light

websites:
http://www.audiojungle.net
http://www.freesounds.org
http://www.djwiij.com/
http://www.cycling74.com/

Stephen Jack Report

Virtual conductor Report - Stephen Jack


Overview

This project is a conductor simulator to give a person with no conducting experience the feel of conducting an orchestra. It allows the user to control tempo and volume by using the wiimote and nun-chuk attachment.

The wiimote controls the tempo by detecting the movements of the users hand, similar in the way a conductor would move there arm to control an orchestra or a band, while the nun-chuk controls the volume with the C and Z buttons controlling the master volume of playback and the joystick controlling the different “spotlighted” instruments.


Related Influential Works

Some influential works include games such as guitar hero, rock band and the upcoming wii music, and works such as wii conductor hero. When coming up with the idea we wanted to do a very basic instrument to start then started going towards the ‘music controller’ games such as those previously mentioned.

While coming up with the idea we also found similar ideas like the conductor hero kiosk, where users control the video playback of an orchestra in a similar to what our project does with audio. A team from the college of New Jersey, led by Teresa Nakra and Chris Ault, designed the kiosk.

Design Motivations

The main motivation for the design of Virtual Conductor was to have a user with no conducting experience before be capable to effectively change tempo and volume of playback. This is achieved by giving the user a simple easy to use system with not too many variables to over complicate the basics of the program. For instance the wiimote is waved like a conductors baton for the tempo control, and the nun-chuk controls all the volume variables, so the main hand controls one variable and the off hand controls the other.

At conception of the idea we wanted to also add other variables such as reverb, Eq, flangers and other effects but to keep it simple for the user and processing power we purposely left these features out.

Technical Methods of Execution

To execute our Idea we decided on the wiimote with the nun-chuk attachment would be a suitable user interface for our goals. We used the aka.wiiremote Max/MSP patch to connect to the wiimote, then decided what information from the inputs we where going to use as well, such as only needing one axis of the accelerometer information coming from the wiimote instead of all three (determining the beat).

This shows the information that we use, coming from the wiimote.

Once we determined how to recognise the beats we choose the IRCAM software supervp.play~ patch to control all of the real-time pitch and envelope correction when the tempo is changed. This patch worked successfully but is rather processor intensive.

When the supervp.play~ patch was introduced it worked well on up to three tracks but upon the fourth track it started to test the DSP power of the computer. This problem was overcome by making the patch run in mono instead of looking at a stereo buffer. Now with four simultaneous tracks running there is no signal distortion due to processor power.


The mapping of the nun-chuks joystick information was as easy as determining which locations to select then created a decision tree that allowed us to define the parameters of the values coming from the joystick.

There was also use of smoothing on the volume buttons so the changes seemed not so sharp and obvious but smoother. This was used on both the ‘spotlight’ joystick and the master volume buttons.








User Experience/ User Considerations

We wanted the user to experience a fun interactive event where they will be able to determine their success themselves by the change in the output. As stated earlier we wanted it to remain simple to keep the users experience fun and enjoyable and not laboured and boring.
Some user considerations would be that we kept the controls fairly simple to use and not being counter intuitive.

Here is the current GUI interface for the program it is very simple and is mainly for connecting the wiimote to the computer.







Possible Changes/Additions


There are some possible changes or additions to the project that would be possible for future builds. One is the ability to record a take of the ‘conductors’ performance in the way they manipulated the play back. Another would be the ability to load your own tracks into the software for playback instead of pre-programmed tracks to possibly create a mixer. Also the uses of a better GUI interface to make the program easier to use for the ‘conductor’ without having an operator there.

One idea that was a possibility at the conception of this idea was that of intergrading effects, such as reverb, delay and sweeping EQ, into the program. This wasn’t done as we wanted it to remain simple and the addition of these extra features would detract from the simplicity of the two parameters and two hands ethos we where using when creating. It is however possible in future builds to include this feature for the user to choose whether they want this feature on or off.

A possible change suggested to us was to change the way an instrument is ‘spotlighted’ by the nun-chuks joystick. To change it would be a variable gain by how far away from the centre of the axis the joystick was, to have a half emphasised value. Also was suggested to have a hold function to allow better “mixing” of the sounds together, working more like a mixer.
Some last minute additions where the inclusion of the play, stop and tempo reset buttons so the ‘conductor’ could control their performance entirely from the wiimote.


Resources

The resources we used where:
• Mac Book Pro- for both designing and running the application
• Max 5 demo version – for building the program
• Wiimote – get ‘conductors baton’ information via accelerometers
• Nun- chuk attachment – gain control
• Logitech computer speakers – audio output from the computer


References

www.iamas.ac.jp/~aka/max
www.ircam.fr
www.cycling74.com
www.tcnj.edu/~pa/video/conducting08

Druidic Rituals - Matthew Shriffer

Brief Overview/ Design Motivation

Druidic Rituals is a multi-user fantasy installation modelled on a modern-day mythical or religious ceremonial experience. The idea behind the project was to create an ambient environment that encouraged user activity and place them in a setting not normally encountered in society to enforce a purposefully detached and immersive experience.

The installation consisted of three separate pillars, on top of each was contained a glass bowl half-filled with water. The pillars were arranged in a triangular pattern with three loudspeakers opposite each one. The idea was to get users to trace patterns in the water with their fingers, or wave their hands above the waters’ surface in order to take part in the “ritual”. Drone/noise based audio loops were then generated according to the motion above/in the bowls, and subsequently played in the surrounding loudspeakers.

The setup of the installation allowed for a tiered approach to interactivity between the users – if one person was taking part, they would hear the noise specific to their pillar all around them. But if two or three people were taking part, a layered wall of noise would surround the area.

Technical Method

The core of the installation was a PC laptop, running a program created by myself in Max/MSP/Jitter 5.0. Three USB cameras were contained inside the pillars (made of PVC tubing) and were connected to the laptop, as well as a Digidesign 002 rack mount unit (via FireWire). Three active loudspeakers were connected to the 002 rack’s audio outputs.

The Max/MSP/Jitter program was designed to detect hand movement, using the cv.hit.HSflow object, and use it to trigger a pre-recorded drone/noise loop. I created these loops in Reason/Pro Tools using a combination of digital samples and my own analogue recordings of guitar feedback and effects. The XY pixel displacement measured by the optical flow tracking method was also programmed to control the overdrive~ object level and pitch of the loops respectively.


Influential Works

The project was influenced by ambient works from Brian Eno (Music for Airports, Discreet Music, and Ambient 2 with Harold Budd), Peter Wright (At Last a New Dawn) and William Basinski (Disintegration Loops series).

More noise-based drone works also contributed major influence to the final aesthetic and atmosphere of the installation, such as works by bands like Sunn O))) (Black One, White One/Two, Altar), Earth (The Bees Made Honey in the Lions Skull, Sunn Amps and Smashed Guitars, Hibernaculum), Growing (Colour Wheel), Magic Lantern (At The Mountains of Madness) and Sonic Youth.


User Experience/Useability Issues

The user experience was loosely documented by me through monitoring and surveying of the users and analysis of comments/criticism received verbally through conversation.

The main concern that arose after this documentation was the issue of indecisiveness and confusion as to what the user is actually supposed to do. I noticed a few people looking at the glass bowls, not knowing whether to touch the water, or wait and see what happens if they do nothing. It was only after I sidled over and encouraged them to dip their hands in the water that they comprehended what was meant to happen. I think this is quite an obvious useability issue which could have been solved with some simple instructions – although I feel this would have taken away from the surreal and detached atmosphere I was trying to create.

Apart from this issue, most users seemed to enjoy creating music using a different and tactile method, and were quite intrigued as to the different sounds created by each pillar, moving from one to another as they viewed the exhibition. I also feel that the simplicity of the design encouraged it to be used by anyone with a childish desire to get their hands wet – and considering the weather at the time, this ended up being most people!

Thanks to Sam & Kirsty for their help in realising my project idea and helping to execute it in the exact way that I had envisioned it.

Sunday, October 5, 2008

Virtual Conductor-Nicholas Verdos

Virtual Conductor- Nicholas Verdos


Brief overview description

Virtual conductor was designed to be an interactive Wii remote controlled experience where a user was using the Wii remotes to control music and be a conductor of a piece of music. The idea of how we would implement this changed during the designing process. We eventually came to a conclusion that instead of it being an advanced conductor simulation we thought it would be more user friendly if it was a piece of music that the user had simple controls over such as volume of each instrument and tempo of the piece. It was broken up into four pieces of controllable sections of the musical piece and that was woodwinds, beat, strings and brass. A nun chuck on the left hand controlled the volume of the piece and of each instrument and the right hand which held the Wii remote controlled the tempo of the piece so as you swung the remote up and down, like a conductor, it would speed up the tempo according to how fast it was being swung. The music itself was conducted by use and we specifically wanted a composed original orchestral piece that had build up and feeling in the song to give the user a chance to put emphasis with the volume control on certain instruments in the song, which in my opinion turned out exactly how we desired in the final product.

Related and influential works

Some specific works that gave us ideas and influenced our basis for our design were games such as Wii conductor hero, guitar hero, rock band, singstar and the new upcoming Wii music game.
We initially wanted to make something musical and just wanted to make a visual conductor where you didn't need a wii mote but we thought the wii mote would act as more of a conductors stick and make it easier and more responsive other then video capturing.

Design motivation

Our motivation for our end design originated from each of our musical backgrounds we wanted control music using gestures in a similar way to which a conductor controls an orchestra. Our motivations are those that are mentioned in the influential works such as wii games where the interactivity from user the triggers music. Our idea changes a lot during the process of designing the system and we decided to take out the gaming experience from our original plans and this was because it was hard to implement in such a short time a way to keep points or some sort of scoring system.


Technical method

Using the IRCAM software supervp play patch that gave us control on the playback speed changes, with limiting the minimum and maximum speeds reachable, while pitch and envelope correction maintained the original patch envelope. The nun-chuck joystick is used to select between the four different streams over audio and puts emphasis on them and the C and Z button controls the master volume of playback. The wii mote controlled the tempo when was swung up and down and would send a signal to maxmsp and there was a max tempo that could be slow down when swung slower.



Above is the maxmsp patches of the programming for the wii mote and nun chuck. The nun chuck when moved the wheel stick would trigger the box on the right and trigger the instruments which were assigned to that quadrant and give it max volume.


User experience / usability considerations

The simplicity in the interface is designed that a person with no musical back ground can come wave their hand to get a varying tempo and use there other hand to adjust volume levels. This I believe is achieved efficiently for the user as there is not many button presses involved for the user. The interface is also defined that the two parameters that the user will control are laid out one in each hand. We wanted the user to not have to practice this to get a hang over how to use this particular software, but more natural in how it works. We wanted to simulate what non musical people believe a conductor does for an orchestra using simple controls. This influenced us to use a simple method of the wiimote and nun-chuck. Our goal was for a user to have an immersed experience through manipulating a musical arrangement. This would require that there are appropriate parameters that may be altered by the user. I believe we achieved our goal quite successfully and gave us a good platform to build on if we wanted to develop the idea more to accommodate a gaming experience or possibly something that a user could use for longer then just the 3 minutes length of one song, possibly by making more songs.




Resources/references

http://uk.videogames.games.yahoo.com/wii/previews/wii-music-orchestra-7d8da2.html
http://www.guitarhero.com/
http://au.wii.ign.com/objects/827/827335.html

Here a few sites of examples that gave us ideas to our final design.

Conclusion

To conclude some of the different things if we had more time, in my opinion, I would change would be I would of made a few more songs so the user has more choice of songs because playing the song it gets a bit repetitive playing the same song. Also more control on reverberation and sustain would have been nice but this was in our original plans but due to technical problems in supervp we could not implement this into the experience cause it would cause it made our system lag to do the processing needed to run. More choice of music would of gave a user a bit more incentive to stay and play with the virtual conductor. Using it myself I noticed once you figured out the song and played it a few times you wanted a new song.

Virtual conductor turned out the way we wanted with all our planning and designing shown when a user grabbed the wii mote and nun chuck they could control the song and conduct how they wanted too.