| Type | Reasonable |
| Description | To create a fake violin and bow that the user can manipulate, and to synthesize sounds and draw sheet music in real time based on the user's motions. The instrument will consist mostly of a chin rest and a fingerboard (proportional to where they are on an actual full-sized violin). There will be some sort of a position sensor on the fingerboard to detect what "string" the user is touching, and where on that string they are touching (most likely, there will be no strings, but there may be little ruts on the fingerboard to help the user "feel" where they would be). Aside from detecting the note that the user plays, there will also be an accelerometer in the bow to detect #1: when the user changes direction (so the user can play the same note over again many times on different bows), and #2: if the user changes speed (this will impact the loudness of the note, and perhaps it can be used to put articulation directions in the sheet music) For user friendliness, the top of the fingerboard should be curved like it is on a regular violin. On a real violin, this feature is to prevent the user from playing on two of the same string when they don't want to. I will use it for a similar purpose here, which brings up another point: to play a note on a string, the user has to both be fingering on the correct string and bowing on the correct string. |
| Who's in the group? |
Me, myself, and I. What I know:
|
| Motivations/use | This has a ton of applications/uses:
|
| How would it be tested? | I would pick out sheet music for three pieces: one "easy" (twinkle twinkle), one "medium" ("Jesu Joy of Man's Desiring"), and one "hard" ("Scheherazade"). Each piece has varying complexity of bowings and rhythms. Have the user play each piece, and record #1: the percent of notes accurately recorded (analyze both the rhythm and the actual note on the scale), and #2: the percent of correct bowing directions detected. |
| What equipment will be needed? |
|
| Timeline for completion | Assuming a 6-week time period of development Week 1: Complete preliminary research, determine feasible options for violin sound synthesis, do some acoustical research about the violin and bowing, determine good options for position sensing on a fingerboard of the appropriate dimensions Week 2:Construct the frame for the violin, begin working on the touch sensor on fingerboard Week 3:Finish and test touch sensor on fingerboard (print note names to the screen continuously), and figure out how to link the incoming data to another language where a GUI can be developed Week 4:Begin developing the GUI interface for composing music Week 5:Finish developing the GUI interface for composing music Week 6:Wrap it up and test |
| Extensions | Provide alternate tunings, change the sound to a different instrument, provide capability to bow more than one string at a time |
| Type | Flaky |
| Description | One of the biggest reasons the Theremin isn't a commonplace instrument today is because of the steep learning curve involved. So unless you're Clara Rockmore, it's doubtful that you'll ever have the patience to learn how to play it right. The purpose of this project would be to facilitate the learning process by making the Theremin a discrete instrument; that is, I will devise a way to get a theremin to "round up" or "round down" to the nearest note based on the user's position (kind of like a singer using an autotune). This way, there will be a discrete number of notes that the user can play (presumably notes on a certain range with half steps). I may give the user the opportunity to calibrate the instrument, or I may just have a set of base frequencies that the computer will round to. |
| Who's in the group? |
Me, myself, and I. What I know:
|
| Motivations/use | Mostly recreational; the instrument can be used for cool effects in songs. Making the theremin a "common man's" instrument |
| What equipment wil be needed? |
|
| How would it be tested? | Test the transitions between notes by moving the hand away from the antenna slowly, and ensure that everything is, indeed, discrete. |
| Timeline for completion | Assuming a 6-week time period of development Week 1: Obtain materials for building a theremin, do research for feasibility (real-time processing, determine if a digital filter can be made. Presumably some sort of modulation will need to be done to shift the signal up or down) Week 2: Begin construction of theremin, begin creation of digital filter (if applicable) Week 3: Finish construction of theremin and debugging of theremin, without any modifications Week 4: Work on getting signal from theremin into the computer, test out some simple filters and see how it sounds in real time Week 5: Finish the digital filter to discretize the analog theremin instrument Week 6: Finalize and test |
| Type | Far-Fetched |
| Description | To have a skateboarding deck that's glued to a mount with force sensors on it that can detect where a user pushes off of it. Then, to render a 3D image of a virtual skateboard to the screen that flips appropriately based on where the user kicked it. Also, perhaps a pressure sensor can be put on the back of the skateboard to ensure that the user is not on the board when it tries to flip (because in real life, the board won't flip unless the skateboarder lets go of it with his/her feet for a period of time). |
| Who's in the group? |
Me, myself, and I. What I know:
|
| Motivations/use |
|
| What equipment wil be needed? |
|
| How would it be tested? | Bring in someone who can do certain tricks, have them go through the motions, and see if the board flips on the screen as expected. Specifically, note the number of times the board flips around the different axes (x, y, and z). See if pushing off harder gets the board to flip more rigorously. |
| Timeline for completion | Assuming a 6-week time period of development Week 1: Obtain materials, do more research about the physics of certain tricks Week 2: Start working on the 3D simulation of a rotatable skateboard on the computer, and start positioning the sensors on the deck and testing their readings Week 3: Begin linking the deck to the computer simulation Week 4: Test/debug Week 5: Test/debug Week 6: Finalize |
| Type | A Joke (maybe) |
| Description | I always get frustrated when people are in their own world and don't pay attention when I'm riding my bike. Sometimes, people do unexpected things and dart out right in front of you, and then you have to swerve to miss hitting them. Also, sometimes riding the bike can be a bit monotonous day to day. I propose that a computerized system be attached to the bike that blares a set of theme songs / special effects sounds while I'm riding my bike based on the following parameters: time of day, mood, acceleration/deceleration, and weather. This way, nobody will be surprised when I'm coming their way, and my transits to and from class will become a lot more interesting |
| What equipment wil be needed? |
|
| How would it be tested? | Ride one day with it and one day without it. Record the number of near accidents in both cases, and the number of bizarre looks that people give in each case |