front page

Miss meer plaatjes?

of juist meer plaatjes als verhouding met de tekst?

---- Moeten lettertype nog ff veranderen! ----

Als goed is heb ik iedereen zijn deel erin gezet

2245710

12

13

14

18

“Design is not just what it looks like and feels like. Design is how it works.”

- Steve Jobs

Introduction

Project GMIS, which stand for Group Mu-sic Improvisation System, is a project where we have to create an instrument. This instrument has to be able to interact with other instruments of the GMIS group. Each instrument is connect-ed to the OOCSI network, a network which re-ceives and sends signals to other instruments.

Project Lumus; a combination of the words Lux and Music, is the first project in our Industrial Design ca-reer. Lumus is a part of GMIS, a project for first and second year ID students in the space of Out of Control.

Lumus is an instrument which is based on light and movement. Laser beams are spread across the room and by interrupting one or multiple laser beams sound can be made. Generally, laser beams are invisible, but with a little smoke the laser can be seen. However there is no physical touch. Play-ing music will be a bit more difficult, but once you got the feeling, you can make nice sounds.

“Lumus a complete new design”

To give the design the ability to not be fixed but to be able to move around, it was decided to create mul-tiple parts that would together be the instrument. By doing this we gave the instrument its flexibility, the size can be determined by the space available.

1

At the beginning of the pro-ject, we were tasked with com-ing up with several viable con-cepts. With brainstorm sessions, body storming and summarizing, the first concepts were created. These concepts were elaborat-ed with sketches and some re-search. Among them, there was:

a dancing tile system (1); a full-body movement suit(2); a hand gesture remote sys-tem(3); a laser guitar (4).

Somehow we really enjoyed cre-ating music instruments which require a lot of movement. Af-ter we put our thoughts on pa-per, there was a presentation about our main idea to the pro-ject group which was our first assignment in DG000. During the feedback session, feedback was given that there should be no limits space and creativity. Think out of the box, don’t lim-it yourself to something small. Make it as big as you want. After this feedback the decision was made that we should step away from what we consider music and musical instruments more.

We went back to the draw-ing board and came up with an idea that still involved la-sers, but was not comparable to any other instrument on the market. It would consist of

several round bars with lasers in them, which formed a cage in which the user would stand and create music by touching the laser beams. It was a step in the right direction, but we lat-er determined that we wanted our device to be more flexible.

We then ventured into several other concepts, most of which involved lasers. We were contin-uously looking for new possibil-ities, as one of the main drives behind our project was the will-ingness to try new things, and experiment with musical experi-ences that were never seen be-fore. Eventually, we were mostly let on the idea of using lasers for the interaction between human and device, but the shape of our system drastical-ly changed as time progressed.

We separated the cage into several separate poles that contained the lasers and mir-rors, which were necessary to build a ‘wall of light’ that sur-rounds the musician. We felt that these final changes created a concept that completely em-bodied what we had in mind. It meant that the instrument could now cover a space from a square meter to an entire room, making it incredibly flexible as an instrument. Since lasers are invisible, we added a little smoke to make the laser visible.

1

2

3

4

Ideation

Design Process

2

3

(1) The Dancing Tile system

(2) A full-body Movement Suit

(3) A hand gesture remote system

(4) A laser Guitar

VisualizationIn the weeks after the first phase, we focused on visualizating our project. By prototyping, user test, history of electronic music and 3d models we made it to our first prototype. After the Demodays we used the feedback to improve it.

- 3d model -

From idea to concept is sometimes hard to realize. We started by making 3d models to know how it will look. After the first 3d mod-el we found some possible problems that can happen in the future. We tried to pre-vent these problems by discuss about it. We made for every pole a 3d model to find the weaknesses and the strenghts of our design. The pole wasn’t stable enough so we prevent this by making a footrest.

3d Model helpted us to rethink about the design and we changed the design a bitt.

- Prototype -

After the 3d models we builded a prototype. We tried different wood thicknesses, nails and screws. We wanted to make it as small as pos-sible. So we chosed MDF of 8 mm thickness. Screws and thick nails will splitt the wood so we used nails that weren’t thick. When the design was drawed on the MDF we saw everything as precisius we could. While building some spaces became so small, we were nessecary to change it. Also make it stable enough so it wouldn’t fall.

Feedback was one the biggest influences we started to rebuild our prototype everytime

- Electric Music -

This research mostly consisted of investigating different sounds from various periods in the history of electronic music. We developed a taste and vision in what kind of sound we de-sired for our instrument, which was a massive step in our own visualization of the pro-ject. The end result of this research was a video in which we summarized the way genres emerged and developed throughout the years, what artists played a role in them and what they sounded like. Eventually, we decided that we would like a retro-type sound. At this time, we had not yet decided how we would generate the sound that the instrument would make.

“build, test, rebuild, it’s an endless loop of designing”

4

User testInterrupting the lasers was one of the first reactions of the users who were let in a room without information what to do. Besides interrupt the lasers they begon with first one la-ser and later with many at once. The user tests gave us a good idea of how intuitive our de-vice was, which was one of the core values that we determined in our vision. Their feed-back was an inspiration bron for us. With much feedback we went back to the drawing tables,

for the project. We also wanted our instrument to have a spontaneous and fun character. To achieve this, we went with a simple, unobtrusive design for the first prototypes. The most no-ticeable part were the lasers, which is the part that the users should be tempted to touch.

During testing, we noticed that the lasers can only be seen from certain angles, but this did not turn out to be a problem while using the device. The lasers could be seen well, but the lack of physical feedback when striking a tone gave it a futuristic feel that the musicians needed to get used to.

After every test we did, we looked to the outcome and went back to the draw-ing tables. First we discussed the outcomes and we took the valuable part out of it. Then turn this information not only in a learning moment but also in our prototype.

4

5

A fter the demo days, decisions had to be made regarding to the feedback we received. Since there were a few flaws to our design, we took the chance to evaluate and redesign. At that moment, there were problems regarding the receiving pole and the mirror structure. The laser beams which had to be aimed at the LDR sensors were very difficult and time-con-suming to aim because the LDR sensors on the receiving pole had very small areas. Also the design of the mirror structure was not very pleasant. It didn’t look very agronomical and wasn’t very stable. Design changes had to be made, so at this point we started to make new dummies to replace the receiver pole

and mirror structure.

The design of the receiver pole had changed to a lower, much more stable receiver box. The area where the lasers had to be aimed was enlarged and inside the receiver box re-

flecting surfaces were

added so more light would fall on the LDS sen-sor. By making the receiver box smaller, it was also more stable, and in addition, adding the

electronics was much easier.

To improve the flaws of the mirror structure, which was that all mirrors were on the out-side of the pole, small dummies and proto-types were made. To limit to a single mirror, multiple designs could be made and the best one could be used. We moved the mirrors in-side the pole and made on each level a 360 degrees horizontal motion possible. Also a feature was added that the laser beam could be redirected upwards, or backwards. This makes the mirror structure more flexible and

more options were available.

New iterations and small adjustments

6

The final design changed bit by bit. By add-ing small improvements and adjustments lots of previous problems were solved. At the beginning, each laser beam was sent by one laser, so in total we used 8 lasers. This is very inefficient. We redesigned the laser structure in which we only needed 2 lasers, instead of the originally 8 lasers.

This resulted in fewer lasers, but an equal amount of laser beams, and the fact that it was much easier to readjust the laser beams.

During the redesign process, program code was written. At the midterm demo day, we presented our concept with a poster and prototype, since we were not able to show a demonstration yet. The first program that was written was a program in Arduino in which we could see whenever a laser was interrupted, or vice versa. At that moment, we could test if the LDR sensors could de-tect the difference in light intensity and im-plement more sensors. After that other program codes were written such as; Read-ing Arduino signals in Processing, playing music files in Processing and sending and receiving signals from the OOCSI Network. All these program codes could be combined to one big program, but modifying was easier this way. see appendix 1.2 .

The poles that we started with were quite clumsy and impractical. They were hard to move around and when someone even touched the pole, it would start to wiggle immediately. When these problems sur-faced, we immediately saw that these would be mayor problems. To solve these prob-lems, we started to try out different bases and we tried to make the design more effi-cient in the way that it occupied space. The problem with the wiggling of the poles was solved by using a base plate with a cross.

This greatly reduced the wiggling of the poles a lot, but not all of it. It will still wiggle when you push it too hard. So we changed the design another time and we combined the two laser poles. But we wanted that they could move free of each other in a certain angle. From the base plate with cross we made a huge improvement to this footrest.

7

So we went back to the drawing tables and start to use the feedback for an new design. We started with the lasers and other things like said before. But here are some sketeches we made after the demoday.

The new pole but now with 1 laser instead of 8.

The new design to go from 8 lasers to 1.

The technique behind the mirror pole

The new receiver

8

Once the prototypes were finished, the electronics which were required could be installed. The LDR sen-sors were tested and could now be implemented in the receiver box. The problem we faced was that in cham-ber where the LDR sensor was placed, had a differ-ent light intensity. Some la-sers wouldn’t fall 100% on the sensor, so some signals would not be registered. To solve this matter, each sen-sor circuit was measured and the right resistor was added. This problem could be much easier solved if we could use analog pins. However, the Arduino only possesses five analog pins, so we were not able to use all eight sensors. An analog pin, gives contin-ues values, compared to the digital pin we used, which gives only a ‘0’ or a ‘1’. With the continues values, we could calibrate the sensors using the Arduino program, instead of changing resistors.

All program files were com-bined. Since every single program was working, it was much easier to combine them together without big prob-

lems. Everything was tested and we made sure everything, included the interaction with other instruments worked. At the end, we were adding the last adjustments to our instrument. To make it vis-ually look better, and hide all flaws which were small mis-takes during the prototype process, the instrument was painted. During the paint sessions, we realized that the paint we used, wasn’t very suitable for the materials we used. The paint, even with a layer of primer would not at-tach to the wood. It took moretime, and more layers of paint to make it look good. But at the end, our instrument was ready for the final demo day.

We did some research to LDR’s because we found out that every LDR has his own resistance value. We meas-ured this with a multime-ter. Besides his own resist-ance value, every LDR need some time to change in re-sistance. So if you interupt the laser too fast it can be that the LDR didn’t pass the margin to get registrated. See appendix 2.1. and 2.2.

Finalizing

9

Excel document

Electric Circuit

10

We presented our v1-pro-totype along with a poster, video and pitch at the mid-term demo days to a few fel-low students and two coaches. They were very positive about our concept, and we received some useful feedback. They suggested that we could im-plement some multiplayer fea-tures, which we had already considered before. By the time of the demo days, we were

already developing LUMUS as a device that is capable of maintaining multiple users. They also suggested that we could invert the concept: the laser would be in the hands of

the user. We toyed with this idea for a while and worked on a possible concept, but we ultimately decided that laser poles were the way to go. Finally, we received some tips on the adjustments of the lasers, and how we could improve the ergonomics of the system. We took this feedback and made sure that the lasers were set at the same height as moving body parts for most people, which made making music with LU-MUS even more intuitive.

Midterm demo day and feedback reception

11

T he very last phase of our project were the final demo days, where we displayed our v2-prototype to fellow stu-dents, coaches and our asses-sor. We had finished everything in time, and thus we were able to present two laser poles, a reflector pole and a receiver box. It all came together into a working system that ran via the Arduino unit. We did run into some technical problems on the first day. The room in which we were presenting our device wasn’t very dark, and there was a steady airflow away from the closed room. This meant that the lasers were dif-ficult to see at times, and that

the smoke almost immediately evaporated when we released some into the room. We also had some software-related dif-ficulties. When the program would be running for a longer period, the data would stack up which significantly slowed down the program. This meant that the sound became warped and stuttered. A simple restart would fix the problem, but it was still something we had to deal with every half hour or so. Other than that, the days went smoothly. We made many peo-ple enthusiastic about our vi-sion and concept, and we were happy with our end results.

Final Demo day and feedback reception

12

Sacha PrudonIn the first week of the project, I wasn’t very sat-isfied with my personal progress and place in the team. Especially during the ideation phase, I found it hard to be vocal about my ideas and suggestions in a team of complete strangers. This, in turn, made it more difficult for me to find in-spiration and motivation for the project. I like to think that I’m a self-conscious person. I think a lot about how other people perceive me as a team member, and how I can make the best of my own and their time. But now, I felt useless. In the pressure cooker of week 2, I tried to take a lead-ing role from the start and I think I succeeded at that. This gave me the confidence to become a more diverse and useful team member in the main project. I didn’t only become better at pre-senting my skills, but also at finding new ways to contribute to the project and team atmosphere.

After this first phase, during which I wasn’t very happy with my progress at all, I started feeling a lot better about how I was doing in the team. I found my place in building prototypes, creating sketches and making our concept better every day we worked on it. I also excelled in making videos of our progress, though I did tone that down dur-ing later stages because I didn’t learn much from it. That’s what I was looking for: new knowledge, new skills, new ideas. I found a lot of those within our project, I consider it a very valuable time in my development as a designer. Not only because of the things that went well, but also because of the way we dealt with problems that we ran into.

As much as I appreciate our final product, the road towards it was far from smooth. Not dur-ing the first stages, but as time progressed, the distribution of work among the team members became heavily unbalanced. We couldn’t rely on the work getting done anymore, and much time was wasted trying to get things done when deadlines were missed or ignored. It was pain-ful to see that a division started to form in the team, something that I did try to prevent. After a while, though, it became clear that something had to be done. We addressed our coach and said that it couldn’t go on like this any longer. This meant that someone beside the team was aware of the situation, but not much actually changed. We didn’t give up, though. Even as a team that that wasn’t completely functional, we made it to the finish line. We were limping to-wards that finish line for a while, but that makes me even more proud of our accomplishments.

All in all, this project gave me a great idea of the versatility of learning moments, new skills and problems that you can run into during a design process. The far majority of the time, I was feeling great about the work we were do-ing and I’m glad I had this experience. I’m looking forward to the next projects, experi-ences and people to work with. Hopefully as a leader, definitely as the best version of myself.

Reflections

13

Kevin LuIf I look back at the whole design process, I can see how much everyone has improved them-selves. At the beginning of the process, everyone was bringing suggestions and great ideas to make Project Lumus happen, but along the way, I saw everyone taking his own spot in the team. Com-munication and teamwork improved a lot and the work efficiency went up. Each member had his own task and tried to make the best of it. At the end we worked all on the same project, but every-one had learned and improved something else.

How I have developed myself during project Lu-mus looks is exactly how I had stated it in my PDP. This semester I wanted to make a beginning with exploring all the competencies, and furthermore I wanted to reach with certain competencies a level of awareness. I had chosen to take the role of making the program code and prototyping.

As I had stated in my PDP, I had no real expe-rience in making programming code. Regarding this issue I started with exploring the basics of programming. I learned very much just by com-paring example codes and making small chang-es to it. To me, it was very difficult to start from sketch, so using examples in the library and at the internet helped a lot. In the second quartile of this semester, I followed the elective Creative Programming. Creative programming taught us more about all basic functions and explained how it worked; it broadened my basic knowledge.

I also helped with making dummies and creating prototypes. Working with my hands improved my crafting skills and helped to a better idea of visualization. Making dummies and prototypes taught me that not everything you sketch or model, can be made. There are limits regarding the material we used. The difference between the craftsmanship of the first and final prototype is significant. Much more details and refinements made the final prototype look much better. My formgiving skills were significantly improved.

As team we took decisions new ideas and ad-justments in our process. By sharing each other thoughts you gain a new perspective. This was for me very useful, because I was very focused on my perspective. Working together helped me to get an overall better view of the process.

In the next semesters I would like to improve other competencies as much as I did for this semester. I want to put more emphasis on the other competencies such as user perspec-tive and designing business process. I want to keep developing myself as much as possible.

14

Pepijn MichelsThe first things that comes to my mind if I take a look at the difference between how I was when I started this semester, and how I am ending this semester, is that I see improvements, shown and yet to show. I do see some development in how I stood in the design process. I do no-tice that how I developed is not how I expected it to go, as I state in my PDP. I was confronted with problems that I had, and I learned differ-ent things than I thought I was going to learn.At the beginning of the project, I was motivat-ed and filled with ideas for our instrument, pro-ject Lumus, just like everybody else in my group. Because we all had our own ideas on how our instrument would look, we all had to compro-mise and take decisions. This brightened my view over teamwork in the form of not focus-sing too much on my own views, but also look on the project from my teammates point of view.During the first weeks of the semester, we had meetings in which we had to do challenges which were related to our project. These chal-lenges contained things like different methods to come up with ideas for an instrument, and how we could visualize it. For your design pro-cess do you have to make some kind of plan which describes the road which you have to cover to get to your final design. During these weeks, I started to pick up on how the path of a design process, of a project, roughly looked. After these weeks, somewhere halfway of the se-mester, we had to organize our own planning on what we had to do to finish our project. During these weeks I was confronted by my coach, Sjors Eerens, that my attitude was decaying, and thus I was letting my team down, and that I really had to start investing more work into the project again. I acknowledged this, and saw that it happened

due to the fact that I was thinking too easy about the project, thus letting my involvement decay. To keep this from happening in the next semes-ter, I have to keep myself busy with my project, and possibly keep a logbook saying what I did per week. I am very glad that he pointed this out to me, and I started to change my attitude to the project and tried to be of use again. Due to this, I felt like I lost my place in the team, and was try-ing everything to get it back. This taught me that when you work in a team, you have to keep up to date and that you have to communicate a lot.After this decline of productiveness, I started to be more involved into the project and I start-ed to work on the Processing code with Kevin. Before I did this, I had no knowledge on how coding works. Doing this, I picked up some ba-sic knowledge; thus being able to write simple codes and see what stands for what, on coding in general, and in coding programs. This most-ly improved my integrating technology skills.I also helped with making the prototypes and the final product. This improved my crafting skills and also helped me to visualize the designs I had created with my drawings. It showed me that when you visualize something with sketch-ing, you have to create a plan on what you have to use, and how you are going to build it. It also showed me that materials have limits which you do not experience when you sketch it. In these ways did it improve my form giving skills.In the end I do think I have not done and im-proved myself enough in this semester, and I would like to improve myself more in the next semester by being more involved in the project and spending more attention to it.

15

Mark RijkersLooking back at the project, at the end everything went really well. With some ups and downs we came to Lumus. Everybody took his place in the project and with result.

In the first phase of the project we came up with ideas. I wasn’t very satisfied of my own participa-tion in this progress. I found it hard to talk in a group without knowing anybody. So I was more silence in this progress. In week 2 I got a pres-sure cooker and it went better, because here we did first tell something about yourself to break the ice. So this I will take with me to my next pro-ject. Like I said in my PDP I didn’t want to take the control of the group in the beginning. After some time I came to the conclusion I found it re-ally hard to just watch and don’t take the control. I want to know what everybody is doing and how far we are. But I didn’t do it this time. But there was one pitfall, when nobody has the leading. Nobody could be punished when he didn’t do his task or came too late. I didn’t take the leading role but I wanted to know my position in the team. So

in between I learned my team members so I knew what they could and what they want to learn.

I didn’t had any experience in Arduino or Ar-duino language. In the project we divided the head tasks and I chose for the electrical part. I didn’t know much about electrical circuits or sen-sors. But I learned to use the most sensors and actuators even how to write a code in Arduino. We reflected much about our progress and here

I learned that some people don’t dare to say exactly what they think. I tried to create a so nice as possible environment for everybody.

Making dummies and creating prototypes was something I wasn’t that good in. But I tried to do so much as possible. Someone in my group was way better than me in working with those machines and he helped me. He learned me how to use those and when to use. But sometimes you design something but you are limited regarding the mate-rial. The second prototype we used other material and also the building on his own was much better.

As team we took the most decisions togeth-er because we didn’t got a real leader, which was nice. Everybody got his input and we tried to discuss everything. This was very useful to me because normally I’m more a leading per-son and didn’t look so much to others opinions.

With ups and downs we are proud of our out-come : Lumus. Next semester I want to improve the other competencies as much as I did now with those. I’m really satisfied about the improvements I made in this project. I’m looking with anoth-er eye to designs and to my own. But next time I think I take the control again but try to create this environment where everything could be said.

16

Chapter 1.1.

- Arduino Code

Appendix

17

- Processing

18

AppendixChapter 2.1.

- Electrical circuit

19

Chapter 2.2.

- excel document

20