SKETCH THREE: prototype documentation

SKETCH THREE: Our Space - Concept Presentation

Finally, the prototype and everything is done. Last week we gave our final presentation to our instructors. We presented two demos: one showing the functionality of the projects and two the visual conceptual side of the project. Both worked well!! I would also like to give thanks to Jack Sam for lending his macbook to us to present our prototype, because all of our demo trials for Max5 all ended. As of now, the video documentation and the paper documentation are all done and they can be seen on here in a bit.

SKETCH THREE: Our Space Video & pdf Documentation (click here)

For those who are interested in project and would like to further develop what we have made so far here are the following links to the Flash (fla) file that we have created. We have used ActionScript 2.0 for this project, but making this in AS3.0 might be easier. We might update the project later in the future, but as for now this is what we have so far.

Flash project file using Actionscript 2.0 (download by clicking here)

Max MSP project file using Max5 (download by clicking here)

Other then the Sketch Three project being done, my summer finally begins!!! so now that I don't have school what do I do? Honestly I don't know what I am going to do. I am either going to read up on books, watch a few (couple, perhaps a dozen) movies, travel out to the states, watch Objectified, workout, and play some tennis.

SKETCH THREE: prototype update

SKETCH THREE: Flash prototype update - tracking 11 objects!!!

Right now we're trying to get this whole prototype to send a message from maxmsp to flash using the flash server. The only down side at the moment is that an object or a movieclip can only update the values on max msp (float number or number object), but the numbers in max msp can't update the position or anything in flash. We got some feedback from Greg about looking into OSC (Open Sound Control) protocol, which is essentially sending binary data to a server and having those objects be read through the platform.

Currently we looked through several OSC versions such as Flosc which is the flash version of OSC and tried to send values from max msp and to receive values as well. Similar to how Flash Server works, it does the same thing. The OSC only reads the values from flash and only updates the values in Max MSP, but from max msp the value is sending in messages but it does not dynamically update the movie clip for a given instance. Other methods, we looked into Oscar - another version of Flosc - but this one's bridging the two platforms and again comes out with the same results.

As far as the project goes, the flash prototype of the project works well. We have around 10-11 objects all linked and they create a path when in contact with each other. Another thing is that the opacity of the object darkens as the objects stay in close proximity with each other as well. For the Max MSP side the object are being tracked by blobs individually and they are given their own name and x, y coordinates. These x-y coordinates were suppose to be used and sent to the Flash prototype where we can use those individual coordinates and make the objects in Flash move. But this doesn't seem like it's going out way at the moment. We are still trying to figure out how this is working but at the wort case scenario, we are going to demo two different prototypes.

Prototype one: showing the functionality of the project through Max MSP. Prototype two: this will be showing the visual aesthetics of the project which was out visual target in how our interface was going to look for our audience. We are still in beta testing at the moment, but so far we might be sticking to these plans in terms of being able to present and demo something for the following presentation.

Hello YDSHINTO.COM & Project cont.

I just recently bought myself my own domain. SWEET!!! so instead of using the Simon Fraser URL, I can now just use my own domain url. My website is now located @ www.ydshinto.com ... Other then buying my own domain I have 2 more projects left to finish - Animation & Spatial Prototyping. The animation is almost coming to an end and the spatial prototyping project is still under development.

Right now, I am still trying to implement arrays into the Flash Action Script that I am creating. This is so that the project can just run off a simple code but have multiple input. The Flash Server is still in process so I am a bit worried about trying to get information from MAX MSP. The WORST case scenario is that the project is just running off MAX MSP, without the Flash but that means that my portion of the work has gone to waste. So hopefully that I would start to see some good results for the up coming days.

On other news, the 2009 ItaliaDesign layout is almost coming into completion. More like just the pre-studies that I have done before going to Italy. This years ItaliaDesign guys have a lot of context that they are covering. I have yet to see what they will introduce to this years Italia research.

SKETCH THREE: prototype cont.

SKETCH THREE: prototype tracking up to 5 sprites!!!

Update on the project, the flash sprites has at least 5 sprites in them at the moment. The only thing is that the system is very in-efficient, so if there are more then 5 players it won't track them. Right now I am currently trying to find a efficient way of trying to make one main code that will do the drawing and the connecting in flash. For implementing MAX MSP to Flash, I have found AS2 or AS3 FlashSever, which some people online has managed to connect the two platforms. On top of that I have found that flash can do blob tracking, but currently being able to track one blob or if there are two, tracking them as a whole.

The motion tracking I have found is called "Flash AS3 Webcam Motion Tracking", so hopefully I can connect this and perhaps try to take the information from the webcam blob and put it into Flash. If in the best case scenario that the MAX MSP can be linked efficiently to Flash, then we will move the project forward with the MAX MSP blob tracker.

The slide presentation and the research paper are coming along and hopefully by the weekend, the project will be mostly complete and testing will come into play.

SKETCH THREE: project research & prototyping

SKETCH THREE: mock interface through Flash

Over the week we have been looking at the Wii-mote and connecting that to the mac through bluetooth. Finally got it working, but the input wasn't something that we expected. Currently the Wii-mote only detects 4 IR Leds at a time, so we have to reconsider another alternative for our input. Perhaps using webcam and detecting motion might be the best alternative that we are at.

Another take on the interface portion is changing from MAX MSP to Flash. We found that through MAX MSP the coding uses a lot of CPU memory which results in crashing the system. Finding an alternative way of coding efficiently was through Flash ActionScript (2.0 or 3.0). So far we divided the coding into two groups, one working on implementing the Wii-mote with MAX MSP and the other implementing the Wii-mote with Flash. Both are coming along, but still have some tweeking and coding to do. The research portion is coming along and even found out more context that we can use to back up our technical and theoretical point of view.

SKETCH THREE: Wiimote White Board Program implementation

For the MAC, I used the WiimoteWhiteBoard to connect the Wii-mote through Bluetooth. This one was another alternative compared to Johnny Lee's program for connecting the Wiimote to the computer. Hopefully by this week we can get some results in having user testings and fine tweak the patch/actionscript.

SKETCH THREE: project process

SKETCH THREE: wiimote process - connecting IR to MAX MSP

Recently been researching on how to connect the wiimote with MAX MSP (working with the aka.object patches) and trying to get the IR sensor working. We started to implement some new patches and had a chance to get the two lines to connect with each other. Once we get that input working, we can then replace the existing dot and replace it with the location of our user with the wiimotes IR information being received. Areas that we are focusing for this week is the visual aspect in: (1) how are we trying to show this community network, (2) how do I belong in this network in relations to person X, (3) how will I be connected to person X and how do I know that I am connected with them?

Based on last weeks discussion with Jinsil and Greg we talked about having a 'blobs' represent 'us' and as we merge or 'physically bump into' each other, we then create a larger blog that derives from smaller blobs. The way we are 'networked' will be this physical or spatial connection. Seeing how long we were in close proximity and considering the touching aspect. Other recent updates are using the (line $1 $2) and (lineto $1 $2) message boxes to draw out lines in jit.lcd rather than worrying about implementing the expression portion in our project.

References

aka.object patches

SKETCH THREE: project plan + discussion

Project Concept: Working with MAX MSP and using the Wii Remote or a Web cam as input source, we are creating a social network but moving the projected screen to the ground. By doing so the user can visually see this network without having to be restricted to the screen and they can move freely around the space that they are being placed in. We want to create an experience where the user can see how they are connected with each other without having to see this network through a LCD monitor or a projection on the wall. The users can walk around and move through this space while still be 'connected' with that particular user.

How the project works: The user is in a shape of a blob and once another user has either 'bumped into' or has come in close proximity to that specific user, the two will create a larger blob. The more users that are associated or clustered together, the bigger the blob becomes. Similar to the example Molecular Bubbles - an Interactive Art Space by Zack Booth Simpson, as the users associate or have networked with each other, depending on the situation the user can either choose to stay or to walk away from the situation. If the user has decided to stay with the user they have bumped into or want to 'talk' to, a line will link the two users together (a similar visual representation that exists in a Facebook application called "Friend Wheel"). If the user has decided to walk away from the current situation, a line will be created but the opacity of the line will be faint. This differentiates between users that has engaged in a long conversation to those who bumped into each other by accident.

SKETCH THREE: Concept Diagram

With the line being a visual representation of how people are connected together, we would also implement the formation of colors into the blob. If a single user has a red blob and bumps into another user that is yellow, by mixing the two color the two will create an orange blob. From there when the two par away they can mix colors with other users. The wearable material may be something that would be reflective so that the Wii remote or web cam can detect the location that the user's are in. Depending on how we would detect people though reflective material that they can wear or through motion, we are testing out the two and decide which one would be accurate compared to the other. The embodiment aspect would be the idea of if one user 'touches' the other user, then this network is created. This gives some relationship between the two users in a situation that they have both encountered.

Project Process and Members Roles
Yosuke and Henry: Would be mainly programming the main patch in MAX MSP as well as working on receiving the input from the web cam or the Wii remote. We will be splitting up which patch is needed so that when we put them into the main patch, they can be easily used with their input and output.

Raymond and Winnie: Would be working on the wearable material and also working on the process side of the research paper and presentation. Going back and forth with smaller sub-patches that Yosuke and Henry might need, we would all go back and forth on what is already made and what is needed.

Project Schedule Outline

Project Inspirations and Examples

Interactive Projection Screen (indoor)

Touch the Sound - Msakazu Hayase

Interactive Floor - Playing on Light up floor

Facebook Application - Friends Wheel

SKETCH TWO: prototype

SKETCH TWO: prototype - development

Last week we developed our Sketch Two: Prototype with all the bugs being fixed and simplifying the code based on the previous week. We presented our concept from the research that we gathered, our technical research and iteration, as well as present our prototype. The prototype turned out pretty well. The night before the presentation, I added in Greg's max patch on collision detection which seemed to fix the problem that I was having for a few days. By simplifying his code and only using the one's that was needed for our project, I was able to apply the speed detection code.

SKETCH TWO: Collision Detection patch - Greg

Basically the speed detection has a metro that triggers a bang to input a value of 1. With two input containers, if the user can hit a specific point from point A to point B, within a given mili-second (this is adjustable from the main menu) then the monster (sprite) will "die" from the hit. Once all these elements were set we also implemented the scoring system, which Jinsil informed us to add this section so that our users will have a reason to play this game. With a scoring system, the user can collaborate with another user to get a higher score. But again, this is fun playing with a friend (from my opinion).

SKETCH TWO: Speed Detection patch

With SKETCH TWO: completed, we now move on to SKETCH THREE. Essentially it's a project that incorporates all the concept and practice we have gone through from Sketch One - Two and build on what we already have or start from scratch. Personally I would like to put the two together and see what we can come up with.

SKETCH TWO: MAX MSP Patch - Click here

SKETCH TWO: Presentation - Click here

SKETCH TWO: process x2

SKETCH TWO: process - testing with users

Currently still making some changes to the prototype of my sketch two project. Meet with Jinsil and Greg to talk about our process and the areas that we could improve on for the coming week. The project implementations are working fine, but still needs to fix some major areas such as the triggering region and the sprites changing after being hit. Some areas that I will be implementing and testing out would be the color detection and perhaps adding in a scoring system, where it gives the project a purpose for them to play the 'game'. So far my job for the project has been implementing, coding, and testing the concept. 

SKETCH TWO: process - areas of change/implementation

For the coming week the following would be presented during the presentation: a score system, sprite triggering (updated), color detection (updated), starting the game implementation, speed detection (hitting specific sprites), color calibration system.

SKETCH TWO: process - color calibration implementation

SKETCH TWO: process

SKETCH TWO: Max MSP patch part 1

So it's been a week from now since our brain storming concept. I was given the role as the programmer to program the prototype. Began the project with a bit of help from Greg, which he provided us with a few simple patches in Max MSP and used that as a starting point. The concept is based on color tracking, where we can choose what colors to track and use that as a object that will trigger something in our digital environment. Other patch such as "if-statements" and a new object called "change" (takes a value once and if it has been banged the second time, it will not read it. Therefore it's useful when it comes to a situation where you have an object constantly banging another value, but you only want to bang it once and ignore the rest). I used the suckah-object to choose the color that is viewed through the webcam and also tried implementing a few jitter objects, which I have not used as much from the past.

Max MSP patch part 2 - Simplify patch

It is currently 6:30am and I have not slept for the whole night. Probably not until I finish at least 90% of this project and cleaning up the patch so that it is actually understandable. Other then that, I have just got a few job offers from the IxDA which is pretty sweet. They all emailed me back and hopefully I can keep in touch with them as well as being able to send in my portfolio to them very soon. I hope.

SKETCH TWO: prototype

Had a meeting today with my team members (Amanda & Nabil) to discuss some concepts for SKETCH: TWO. This concept for this project focuses on the idea of using web cameras to let the users interact with the "digital" or "physical" environment that they are being placed in. During this weeks lab we touched based on MAX MSP and worked on how to calculate an object move in a window with the jitter function. From that we integrated two objects into one window and added a function when two objects collide a reaction occurs.

SKETCH TWO: brain storming

Our concept focuses on the area of "joy of use" similar to the project by Camille Utterback & Romy Achituv called Text Rain. Where the user can interact with the falling text on screen while parts of their body "catches" the text. As the user "catches" these letters, words or phrases are created with the one's that the user has caught. Our idea is to iterate this concept as a base in terms of allowing the user to interact with what is on the screen while implementing "game play" into the project.

SKETCH ONE: prototype

SKETCH ONE: prototype

This week we finished our Sketch: One project, which included the functional backpack with the pressure sensors (anti-static foam sensors) and the LED indicators. Our project concept: a wearable backpack that has pressure sensors to allow the user to be aware of the amount of weight that they are carrying. The purpose of this project was to reduce the risk of back/shoulder pain through the implementation of a body interface. At the University of California by Brandon Macias, research shows that the some back pains (from students) are caused by the way students are carrying their backpacks and the amount of weight they are carrying.

SKETCH ONE: fabrication process

In our technical side, we used anti-static foam as a replacement for pressure sensors and we connected a 1V current running through the foam. As you put pressure on the foam the current increases (similar to how resistors work). We also implemented the code in Arduino where we gave it a specific range for the LEDs to turn on. Finally we implemented the whole project using conductive thread to connect the LEDs to our Arduino board, hiding all the unnecessary wires. The overall project demo went well and learned a few new concepts about fabrication and implementation on conductive materials. In addition we consider a few changes that we would change in the future, such as positioning the LED's so that the important lights will be visible for the user, working with a functional circuit board, and practicing on wiring/soldering the elements efficiently.

Click here for the slide presentation:  SKETCH ONE - Presentation Slide

Click here for the Arduino Code: SKETCH ONE - Arduino Code

SKETCH ONE: process

Implementing pressure sensor position

Today we were able to complete the circuit system and use anti-static foam as an alternative for pressure sensors. With this material it's soft enough so that when it goes into contact with the users skin they won't feel uncomfortable. We also implemented 4 pressure sensors (2 on each shoulder strap) and positioned them based on how we think that the user might be carrying their backpack.

pressure sensor prototype programming

By using 4 sensors on the shoulder strap, we can calculate the average when all the sensors are being touched. We programmed the sensor in situations where either one, two, or three sensors are being touched the average will not be affected if either one is missing. We implemented the complex wires into one circuit board that was soldered and put together.

For the coming up week, we will be implementing the resistance on the anti-static foam pieces as well as implement the "idea" weight range for either young males or females. We consider the different body proportions between the two genders and found research studies that back up our concept.

SKETCH ONE: self awareness

Jinsil & Greg - Ripping our Mushroom

During this week my group presenting our fabrication circuit to Greg and Jinsil. We had our mushroom working and glowing individually but then Jinsil ripped open our mushroom so that she could look at how the LED's were implemented. Poor mushroom.

After the presentations we brainstormed some concepts for our Sketch One project. The project works with the concept of body & spatial embodiment, where the user can alter his/her surroundings based on a spatial perspective (the user does something to the room and the room responds) or a body embodiment where the device/clothing responds to the movement of the human body. We brainstormed with the idea of self awareness where our user is given feedback based on the action they are applying.

Concept brainstorm

The concept is focused around backpacks using pressure sensors and LED's that illustrate the awareness of weight being carried by the user. We looked into the issue that users are unaware of their body posture when he/she is carry something beyond their limit. This concept refers to university students where they have to carry their laptop, text books, notes, etc. Our objective is to give feedback (through LED's) to the user so that they will know how much they should be carrying and protect their body posture in the future. Of course we can not force the user to stop carrying more weight on them, but the idea is to represent self awareness to those that are not considering their body for the future.

Arduino meets Fabrics

Toggle/Button + Arduino

For the second week we played around with the Arduino and was introduced to how button/toggles and the photo-synthesizer work. The first part in the lab was to create a button/toggle and to make the light blink every time the user pushes the button/toggle. The second part in the lab was to use the photo-synthesizer and have an understanding of light. When the user blocks the amount of light being read from the photo-synthesizer the LED will become dimmer and vise versa the light becomes brighter as more light is shinning on the photo-synthesizer.

Mushroom + Arduino = Glowing Mushroom

Team: Me + Amanda + Nabil

At the end of the lab we had a discussion on the different types of conductive fabrics that we could use for our first assignment. Some of the materials that were new to me was the conductive thread (something I might consider using for a project I have in mind) and carbon tape, which I have heard of but did not have the chance to actually use the material on fabrics. After that me and my team (Amanda Hui & Nabil Lam) played around with the fabric materials and we made our glowing mushroom, which is still in production.

Hello Body Interface!!!

Input/Output Activity Document

First week back to school and I have just meet my two TA's Jinsil and Greg. In our first studio lab they gave us an activity where we are given an input and an output. From the given input/output we were to come up with three examples of either an application, thing, or something that uses these together. At the end of the studio we played with some Arduino and made some awesome blinking lights. Some what reminds me of IAT338 where we made a million blinking lights.

My given input was location and my output was dancing. I had to think about this one for a while because the input made it a little complicated. So the first thing that came into mind was a bobble-head. A bobble-head can represent a specific location, like if you visit the different parts of the states or somewhere in Canada each location will have some kind of bobble-head and as an output they are some-what "dancing" but with their heads.My second thought was people. Since we all come from different locations and we can sing or make our own music without having background music therefore we can dance. Simple. Each individual has their own cultural song/dance so this was one that came up. My last idea an dancing puppet - where you can place this puppet onto a surface (or a location) and it will dance according to the tactile surface that it is being placed on. If the surface is liquid-like, it will move as if its body was made out of liquid or if the surface was soft the puppet will dance as if it was slow-dancing.

In the end we had a collaborative input/output activity and for my group rather then have 2-3 member we made a huge group with 5 members. Awesome. So our input turned out to be: direction, light, brainwaves, location, and time. Our output was dancing, light, fire, time, and water. With a combination of all of these we made a Water DanceDanceRevolution platform. Where a user is placed onto a surface of water that has sensors at the bottom and if they are in a specific location for too long, it omits heat which causes our users to move to another location (hence dancing).