Posted on

Sun A’s Status Report for March 25th

What did you personally accomplish this week on the project? Give files orphotos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

This week, I spent most of my time trying to figure out how I was going to build the hardware system for the upcoming demo. I am planning on building a full octave system with the possibility of playing 4 actuators simultaneously. As of now, I CAN play 4 actuators but I can’t seem to control them individually. Also, in the process of implementing this, I burned out 4 of the actuators so will have to order more for future use… (I will be going back to Tech Spark to figure out the individual control tomorrow though).

 

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

So far, it’s going fine. I think I might be on a time crunch if I can’t figure out why my actuators are controlled by one signal by tomorrow though.

 

What deliverables do you hope to complete in the next week?

First, I would like to finish building the full octave system by Wednesday. And, then I can focus on building a mounting system.

 

Posted on

Team’s Status Report for March 18th

What are the most significant risks that could jeopardize the success of theproject? How are these risks being managed? What contingency plans are ready?

HW: Before this week, my biggest concern was not having enough power but I realized that the power supply I use have +30/-30 and 2 A each — and the maximum power rating is 120W. So, I realized that I can just add 30V/2A and -30V/2A to create 120W power source for the circuit. But now, my only concern is that how I am going to build the mounting system and how we are going to integrate the generative mode. If the generative mode taking too long to integrate by the interim demo, we may have to resort to only doing simple-note-playing mode by the interim demo.

Music SW: The concern this week was data transfer. There are ways to send data to an Arduino over serial, but this data generally isn’t marked as anything specific. So, we needed a way to ensure we can read in data and send it down the proper paths (note queue, actuator system, etc.). Generative mode needs a bit of work, but the hope is that it should be done in time for the interim demo (no point in just hoping, though. I’m also working on finishing it and setting up a data pipeline!).

SW (CV): My biggest concern at this point is detecting without environmental interference causing an issue – the plan is to try to switch it to symbol detection. We could have a specific symbol drawn out on a small piece of paper that is then stuck on a hand, for example, that the OpenCV uses to track where they want to signal. This would solve the issue of someone wearing the signaling color or someone in the background wearing it. The contingency plan would to go forward with color signaling, since that is working, and just isolate the environment with a black backdrop.

Were any changes made to the existing design of the system (requirements,block diagram, system spec, etc)? Why was this change necessary, what costsdoes the change incur, and how will these costs be mitigated going forward?

HW: Not yet!

Music SW: Ditto.

SW CV: No.

Provide an updated schedule if changes have occurred.

HW: None!

Music SW: Same!

Software: None, except working to switch to symbol detection this week in addition to the feedback.

This is also the place to put some photos of your progress or to brag about acomponent you got working.

HW: I was able to power three solenoids simultaneously!

Music SW: Nothing to see, but I set up some pretty nice data structures for data transfer, at least in my opinion.

SW: Looks cool on video, but image captures don’t look much different. Both normal note generation and generative mode is working and you can switch between them which is cool!!

Posted on

Sun A’s Status Report for March 18th

What did you personally accomplish this week on the project? Give files orphotos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

This week, I worked on replicating my test circuit to have 3 solenoids (all powered at the same time). During this process, I noticed that the solenoids were getting heated but that may be due to having them on for a few minutes constantly. However, in reality, these solenoids will not be powered on for 3+ minutes straight so hopefully, we do not have to find a solution for having too hot of parts. I also tried to solder some cables onto the solenoids because the solenoids’ cables are flimsy.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

I am on track!

What deliverables do you hope to complete in the next week?

I am hoping to finish creating (and soldering) the 7 solenoid circuit onto the protoboard by next week

Posted on

Team’s Status Report for March 11th

What are the most significant risks that could jeopardize the success of theproject? How are these risks being managed? What contingency plans are ready?

Hardware: I am a little concerned about designing a circuit and soldering it onto a protoboard. It is more permanent than doing it on a breadboard so I will ask Prof. Tamal, Sullivan, or Budnik for advice if I do come across any issues. There’s really no contingency plan because I NEED to do this.

Music Software: Not much has changed. I’m still planning on tightening up any timing measurements for deciding where the beats fall. The reasoning has previously been elaborated on, but to quickly restate: if the timing is off, the user won’t really feel as though they’re playing. It’s one thing to be off-time because you aren’t matching a beat, and it’s an entirely different thing for your instrument to be off-time from you.

Software (CV): I still believe that color detection could be one of the greater risks at this point, as I started to fine-tune the color detection and it proved to be more difficult than expected. I am still not too worried about this, but the contingency plan is just putting up a plain background or having a set color to use.

“ Were any changes made to the existing design of the system (requirements,block diagram, system spec, etc)? Why was this change necessary, what costsdoes the change incur, and how will these costs be mitigated going forward?

Hardware: n/a

Software: No major changes. Bayesian Updating simplified in belief that a more complex system is unnecessary. However, there are still structures in place that allow for a full implementation.

“ Provide an updated schedule if changes have occurred.

Hardware: everything is going well! on track!

Music Software: On track.

Software (CV): On track.

“ This is also the place to put some photos of your progress or to brag about athe component you got working.

Hardware: got my testing circuit working!

Software: Nothing too interesting to look at on the music side, though you can see some console output in Lance’s post.

Software (CV): more details in Katherine’s post, but the generative mode is recognizing patterns using the grid:

Posted on

Sun A’s Status Report for March 11th

What did you personally accomplish this week on the project? Give files orphotos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

The week before spring break, I met my personal goal of testing and ordering solenoids. A few weeks ago, I bought a solenoid with a 12DC power rating and was not sure if 1) this would fit on every key on the keyboard; 2) would actually draw 12 Watts to play the keys; and 3) if this would even play the keys (like do I need to get a push-kind or pull-kind or even a “bigger” solenoid”). Throughout the testing, I encountered some issues like not finding a power supply to handle the 12DC solenoid and such. But, after talking to different professors and Quinn, I figured out that there were “heavier” power supplies in Tech Spark, so I spent most of my time there testing the solenoid. Anyway, by the end of that week, I ordered 14 more solenoids to start building a one-octave system starting next week.

“ Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

Nope, I am on track!

“ What deliverables do you hope to complete in the next week?

I hope to design a functioning one-octave system — but not completely build it since I will be building it using a protoboard rather than a breadboard. This requires more time to design the circuit.

I am including pictures from the week before spring break:

 

Posted on

Sun A’s Status Report for Feb 25th

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

I was the one who presented for the design review presentation so most of my week was consumed in making the presentation and preparring for it. I also received my orders from Adafruit and DigiKey so I was building the sample this week but I did not get to test it… I will do the testing on Monday when the receiving is open (the keyboard is with the receiving because it’s hard to store a full sized keyboard).

 

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

So far, I am not behind the schedule.

 

What deliverables do you hope to complete in the next week?

I hope to finish testing next week and figure out if I should get a new keyboard (less weight on the key) or if I should get a new type of solenoid. This will be the biggest task for me next week!

 

 

Posted on

Team Status Report for Feb 25th

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

Hardware: the biggest risk that I can think of is buying too expensive of an actuator that I don’t have much left in the budget for other members to use. As of now, I am testing with a less than 10 bucks actuator but if I have to go with an actuator from DigiKey (which is 26 bucks a piece), it will be difficult to plan for contingencies (at least contingencies that would require us to spend money on items that we currently don’t have). If I have to buy 26 bucks a piece actuator, I will have to stick to building one octave.

Software/OpenCV: the biggest risk is probably the accuracy of the color detection and how sensitive it is to other colors. I don’t think I have a lot of risks right now because I have a pretty good basic implementation working that wouldn’t jeopardize the success of the project. To manage this risk, I am researching how to fine-tune the color detection and possibly use depth to ensure the right colors are being picked up. The contingency plan would be to just put up a black curtain behind the user so there is no issue with outside color.

 

Music Sequencing + Generation: the largest concerns at the moment are timing issues and chord prediction issues. If we can’t consistently send notes at regular rates, the feeling of playing an instrument turns into messing with a buggy mess. On a real instrument, being out of time is the fault of the player rather than the instrument.  Although we won’t give our users the option to be out of time, we should ourselves be in time so as to not inconvenience them. As for chord prediction, if our algorithm doesn’t work, we’ll end up with chords that just don’t match what’s being played.  Of course, melody is 100% left to user preference, so they may find it more interesting to play non-chord tones. However, it’s our job to ensure the chord matches the notes as best as possible. I’m also considering methods of how to predict what notes will be played next. On one hand, notes in a key have the tendency to want to resolve towards other notes, but on the other hands, players tend to play notes sequentially. If looking ahead doesn’t work, we can always a random chord selection to play for one phrase while analyzing how the users play, and then change the progression for the second phrase, and so on and so forth. There’s definitely a lot to consider.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

Hardware + Software: no, there haven’t been any changes made to the existing design of the system since I am still testing which solenoid to use. No for software as well.

Provide an updated schedule if changes have occurred.

Hardware: N/A

Software: I (Lance) am considering moving my schedule forward some so that I have time to relax over spring break. Also, sound generation has been renamed to music generation to better fit the direction our design went in. Music generation directly relates to the chord prediction algorithm mentioned above.

This is also the place to put some photos of your progress or to brag about a component you got working.

This is the sample / test circuit to test a solenoid:

 

The computer is now playing appropriate piano notes for the user moving into the note which is very exciting. I tried to show it in this picture of the terminal (it is best seen in a video)

\

Enumerate how you have adjusted your teamwork assignments to fill in gaps related to either new design challenges or team shortfalls (e.g. a team member missing a deadline).

Thankfully we have not had a member who did not meet a deadline during the project. However, Sun A had to post Lance’s status report for the first week because he did not have access to WordPress. Thankfully, this was quickly addressed by Prof. Tamal and Lance and now he is able to post his individual report and contribute to the team’s report on WordPress. Other than that, we have not yet had an incident to make adjustments to fill any gaps.

In the future, because Sun A does not have much experience in fabrication, Katherine will step in to help with the actual physical mounting structure for the actuators. And, given that Lance has a lot of experience in Robotics (as it is his additional major), he will be helping out with any difficulties that might rise while building the actuator system.

Posted on

Sun A’s Status Report for Feb 18th

For the first half of the week, I spent most of my time looking at different solenoid options before placing an order. There are different types of solenoids — push type, pull type, and push-pull type. For the external actuator system, push system might be the most intuitive option; however, push solenoids are more expensive than pull solenoids in general. Then, I looked at Adafruit and found that their solenoids are actually push-pull type and offers a reasonable price for their small solenoids. So, for this week, I ordered ONE small solenoid from Adafruit to see if their solenoid is, indeed, push-pull type and its push is enough to play a key on the keyboard we got from the receiving.

I also designed a super rough circuit to just test the push-pull solenoid, which I am attaching below:

For the testing, I would only need a regular power supply that’s already in the A level lab, but for the future building process, I would need to request a “beefier” power supply, which I will reach out to Prof. Budnik to ask about the model that I used in his control systems class.

Posted on

Lance’s Status Report for Feb. 11th

Over the past week I’ve been weighing options for melody generation. There are a plethora of options because of the nature of music as an artform.

If we choose to let the user directly control the notes they play, then the form is simple. Given some input (grid coordinates for now), we can tell the hardware to press a specific note on a keyboard. The question then becomes, how do we make it interesting? If you’re stuck always playing exactly the note you’re at, it’s not going to sound like music. Well, it will, but it could always be more interesting. Then, let’s say that the other axis of your grid determines how fast the notes are playing, their subdivision. This is fine- and it definitely adds more spice- but there are still some key elements missing. What if we want to “play” a musical rest? What if we want to jump over some number of notes, say, an octave? There are definitely options for this, for example, in the case that we have colored gloves, we could use the absence of color to indicate a rest, which can then be used to make note jumps. This solution should be incredibly intuitive, but difficult to play skillfully at first, which could be discouraging.

If we want to procedurally generate melodies based on two notes at some point, we have a few options. The simplest is to say, “What is the subdivision? If you give me that, I’ll create a string of notes that run up (or down) from the first to the second note, in the amount of time you give me. If there are too many intervals between the two notes to be played, I’ll skip over some of the boring ones. If there aren’t enough, I’ll make some longer.” This works, and we can even add random variations. For example, we could randomly choose to generate a “harmonic enclosure,” which is when you land on a note after playing the notes above and below it in a sequence. We can add plenty of other flairs to our melodies like this. This solution is very versatile, but may be difficult to create a smooth user experience for.

The last solution is something I need to further consider, but it involves generating a melody based on “mood” determined from gestures. We could possibly do this by parameterizing certain musical intervals with various emotions, and then selecting notes based on that. This gives the user a lot of leeway, but also greatly increases the amount of effort needed to create something musically coherent and satisfying to play/listen to. Sure, moving from the 7th to the 1st interval is satisfying, as is a ii-V-I progression, but everything can be used in so many different ways that it’s hard to say what the best outcome would be. This solution, if implemented properly, would be extremely fun to use, but definitely sacrifices some of the user’s autonomy.

As it stands, I am on track to start with pitch selection algorithms and continue with musical progression generation.