P21363: RIT Player Piano

David Anthony Nick Besley Josiah Martuscello Steven Petrick Jeffrey Seamon Electrical Engineering Computer Engineering Mechanical Engineering Computer Engineering Mechanical Engineering Purchasing Lead Project Manager Communications Lead [email protected] [email protected] [email protected] [email protected] [email protected]

Abstract—The goal of the RIT Player Piano project is to the song with their one hand and have the device complement retrofit an existing upright piano with a removable device that them with the other. A piano student could, by themselves or will allow it to be played completely autonomously or as a with the help of a teacher, record their rendition of a song supplement to a human pianist. Imagined use cases include as a rehabilitation tool for those with limited use of one hand, as a while getting feedback on what keys were (and were not) practice tool for piano students, and purely as an entertainment pressed for later analysis and teachings. Or, if a pianist has device. In addition to playing the piano’s keys, the team has an upcoming duet but is unable to practice with their partner, worked to develop the ability to record and get feedback on one’s they can practice their own part while having the piano play performance and control of the sustain pedal autonomously. In their partner’s. The ability to record yourself playing can also order to make the piano’s play sound as realistic as possible, the ability to control dynamics and tempo are included. come in handy when in person contact with others is limited, Index Terms—Solenoids, computer generated music, musical such as during a pandemic or with many people’s normally instrument digital interfaces (MIDI), music information retrieval, busy schedules in general. user interfaces Through the RIT Player Piano, we hope to provide pianists with more tools to improve and/or expand their playing ability, I.BACKGROUNDAND MOTIVATION or just sit back and listen to the music. The piano is an instrument played and enjoyed by people from around the world. With the ability to play several octaves II.DESIGN and notes at varying dynamic levels, the piano is a very This project was divided into five subsystems, with each versatile instrument. The player piano is a variation of the team member being assigned one to focus on according piano which plays itself via pneumatic or electro-mechanical to their academic discipline. Work started with a focus on control. Most player pianos are built this way and are fairly subsystem design, building, and testing before the subsystems expensive to purchase. were integrated toward the end of the spring semester. Each Enter the RIT Player Piano. This is a continuation of a subsystem will be detailed below, while the integrated system now five-year effort to convert a normal upright piano into a will be discussed in the next section. player piano by designing a device that can be placed into the piano and play it autonomously. Users will be able to A. Frame and Solenoid Mechanics select a song via our user interface (UI), select tempo and The main component of the player piano device is the dynamics, and then sit back and listen to the piano play. This is frame that gets inserted into the piano and above the keys. done by inserting solenoids, mounted on a metal frame placed The majority of work on the frame was accomplished in over the piano’s keys, that will strike the piano’s hammers, previous design iterations and allows for adjustability in the playing the notes. Additionally, a linear actuator is used to mounting of components. There are three main t-slotted rails control the sustain pedal autonomously. However, none of on the frame that span the width of the keys (Fig. 1). On the these improvements should hamper an individual’s ability to top two rails, solenoids and various electronics hardware are play the piano normally. mounted. Specifically, solenoids with shorter extenders and The goal of this project is not just to create a player piano; bus bars are mounted in the top rail, while solenoids with we want to help people learn, relearn, and/or improve their longer extenders and PCB brackets are installed on the middle piano playing skills as well. Additional features include the rail (extenders and lengths discussed in more detail below). ability to record someone playing the piano via a microphone The button feedback boards are attached to the underside of the mounted on the piano and feedback on what keys were bottom rail. On each side of the rails are support brackets, into pressed and when via buttons mounted above the keys. We which the rails are bolted (Fig. 2). These brackets have slots have imagined several use cases that have guided our design, which allow for adjustability of the rails as they are installed including: as a rehabilitation tool, to assist a student just into the piano. learning to play the piano, and as an aid to a pianist unable Solenoids are the tool we are using to play the piano. They to practice with their partner for a duet. Hopefully, our device are installed such that they strike the piano’s hammer assembly will be able to help those in the aforementioned scenarios. and not the keys themselves. However, the solenoids we are If someone has lost use of one of their hands, they can play using cannot all sit right next to the hammers, necessitating Fig. 1. Portion of frame viewed as if playing the piano. Solenoids are mounted Fig. 3. Plunger assemblies, exploded view (Fig. 3a, left) and assembled (Fig. on the top two rails and button feedback boards are attached to the bottom 3b, right) rail.

Fig. 2. Support brackets on the sides of the frame. Slots are drilled to allow Fig. 4. Solenoids and plungers assembled with mounting brackets. To be for adjustability. placed on top rail (left) and bottom rail (right).

nut. The slot end gets mounted to the rail using a specialized approximately half of the solenoids being placed on a second, bolt and nut, along with a lock washer. For solenoids mounted lower rail with extenders attached to the plungers. P20363 on the top rail, an additional slot must be cut into the bracket redesigned the solenoid extenders, but were unable to fully to allow for the long extenders to reach the hammers. test and implement the solution before campus shutdown. The tops of the supplied plungers for all solenoids were threaded B. Solenoid Electronics/Power System in order to allow for the installation of the extenders (Fig 3). The solenoid electronics are responsible for operating the For solenoids mounted on the top rail, the extender consists array of solenoids to play notes. The control circuit and boards solely of a hex nut and nylon standoff tightened against each were designed by previous teams. A total of four boards are other. This assembly prevents the plunger from falling through required to operate the 86 solenoids. Each supports up to 24 the solenoid housing, while providing a softer surface with channels. When a note is to be played, a PWM signal is which to strike the hammer. For the longer extenders, more written to the control channel. An optoisolator converts the components are required. A metal standoff is installed on top signal and uses a MOSFET circuit as a switch to provide a of the plunger, with hex nuts on each side, to allow for a variable voltage from the PWM. A schematic diagram follows threaded rod to be attached, elongating the plunger. At the top in Fig. 5. of the threaded rod is a hex nut and a longer nylon standoff. To ensure close proximity to the solenoids while providing For both types of extenders, a rubber o-ring and spring are clearance with the piano’s covers, various locations were placed on the plunger. The o-ring falls outside the solenoid considered for mounting. The final decided upon solution was housing, and is used to reduce the mechanical noise made a 3D printed bracket to mount the PCB’s to the bottom rail. when a solenoid is actuated. The spring is installed so that it In this location, it is clear of the swinging key cover while is inside the housing. This helps with noise reduction as well, also allowing shorter wire runs to each solenoid. but also returns the plunger to it’s unactivated (lower) position With reduced locations to mount busbars because of the quicker to help ensure notes can be played at the desired tempo new board locations to provide the feedback boards space, an (Figure 4). alternative was needed. To solve this problem, male headers Mounting brackets were cut by previous teams from sheet were added to the boards to provide easy connection straight metal and allow the solenoids to be connected to the t-slotted to a corresponding female connector. rails. At one end is a circular cut out and at the other is an inch- To power the solenoids, control boards, feedback boards, long slot. The top, threaded end of the solenoid gets placed and raspberry pi, a comprehensive power system was designed. into the circular cutout and fastened down with a large hex In total, the power supply’s maximum typical draw is 13.2 The sustain pedal is actuated according to Fig. 7, with the green arrow depicting the rough placement of the linear actuator used to engage the pedal. It was placed as far away from the fulcrum of the pedal lever as possible to reduce stress on the mechanical components. The 12-volt linear actuator (specifications in appendix) was chosen for its small size and power requirements, and was purchased by the 18363 team, but the subsystem remained incomplete and unused in the intervening years. It can generate upwards of 112 lb-force. Because of the rough interface for controlling the actuator, it is not reliable enough for displacement based control, and has some attack and release in response time. This, along with the large amounts of force it generates required multiple backup systems to ensure that it did not exceed the 30 lbs of force needed to engage the sustain pedal. Without any safety precautions, this linear actuator could easily tear through the Fig. 5. Control Circuit for an individual solenoid. pedal lever and cause serious damage to the piano.

Fig. 6. Mounting bracket top and side view. Fig. 7. Diagram of mechanical forces in sustain pedal lever. amps. Based on this, 15 amp slow blow fuse protection for 14 The first backup system is a metal frame that prevents the AWG wiring was selected. actuator from going beyond a certain limit (approximately 0.8 cm). Some components of this design were completed by the C. Sustain Pedal 18363 team, but updates were made this year to ensure that The Sustain Pedal subsystem incorporates control of the there is no slippage in the contact between the head of the piano sustain pedal similarly to the way the solenoid array actuator, and the aluminum housing. This system is a last is configured. Within an unmodified piano, the sustain pedal line of defense: if all goes well, it will never be used. The is pressed by the player’s foot (red arrow in Fig. 7), which second backup system uses a switch (blue icon in Fig. 7) to engages a lever and lifts the array of felt dampers off of cut off power to the linear actuator once the sustain pedal the strings. These dampers are lifted individually any time is engaged. This one way switch prevents the actuator from that a piano key is held down, regardless of if it is pressed being extended, but does not prevent current flowing in the hard enough to play a note. The effect of the sustain pedal is opposite direction, so the actuator can be lowered without any that every note is sustained as long as the piano strings will complicated control schemes. ring out. It also allows for additional sympathetic resonance This subsystem fulfills a primary customer requirement, between notes: if a lower register C# is played, the other C#’s which is the ability to control the sustain pedal. Since this on the piano will ring, as well as other notes that relate to that had been left incomplete in previous years, it was reassigned fundamental harmonically will also sound. Needless to say, the as a higher priority, and an entire subsystem was assigned to sustain pedal is an important part of making the piano sound take care of the task. Considering the previous work other human. Sustain support is part of the MIDI protocol that we teams had done, it was not considered an infeasible aspect of are using to control the piano, and is coded as Control Change the project, but because it required completely new support in 64 (CC64) in most consumer MIDI controllers. It is therefore the software and electrical systems, there was additional work already present in many MIDI arrangements of common songs. to be done. Within the feasibility studies we conducted, this subsystem gradually became more feasible, and we decided to whichever buttons are being pressed at one time. The circuit proceed. The previous teams work gave us a direction to go that was created for this design can be seen below. in, which helped remove some of the initial design work we would have needed to allocate here.

D. Feedback System One of the subsystems that were required by the customer is one which provides the player with some kind of feedback. As it has been interpreted this way, there are two routes which have been followed for the implementation of a feedback system. There is a real-time feedback system which allows for the player to see exactly which keys are being pressed at one time. In theory this allows for the player to match up the keys being pressed without needing to take their eyes Fig. 8. Circuit schematic of button feedback boards. off the piano scroll animation that would be playing during a For the microphone feedback system there was not much performance using this device. The second half of the feedback required in terms of design. There was a recommendation from system is the post-performance recording which is completed the P20363 team that the team should acquire a microphone with a microphone such that a MIDI file can be generated with a range of 27-4200kHz to be able to cover the range of using AI tools to play back the performance using the device. frequencies that a piano can produce. As a result the team The customer required that the piano player device be able acquired a Samson GO USB Microphone. The idea here is to record a performance to MIDI such that dynamics can that the microphone connects to the Raspberry Pi via USB be captured as well as a minor requirement of an improved where a performance can be recorded to a .wav file and then training interface. The feedback system’s two pieces satisfy transcribed to MIDI with the use of the Magenta Onsets and both of those requirements by providing the user with two Frames tool. The following image describes the use of the avenues of receiving feedback. microphone in this application as a feedback tool as well as In many instances of piano playing devices, current solu- use with a potential calibration sequence which would actually tions to this problem include the use of more complex optical satisfy another engineering requirement set by the team. sensor based systems. These kinds of systems are able to The concern in regard to feasibility for the real-time feed- provide real-time feedback as well as capture dynamics in back system pertain to the interference that the buttons would some sort of recording, which were the main engineering have on the keys, having them come in physical contact with requirements for the feedback system as a whole. While this them meant feasibility had to be performed to ensure that the would be a more succinct solution, there is simply not enough button system would not violate the customer requirement that time or budget in the project to be able to properly design and the piano must be played without any interference. The P20363 implement this solution. Since there is a desire to complete did the work regarding the feasibility, these results were trusted the project soon, the current implementations should suffice and just examined slightly to ensure that the design was in fact per the customer’s requirements. valid. For the real-time requirement for the feedback system, One additional measurement taken was in regards to ensur- rather than using optical sensors to detect when a key has ing that the current drawn by the device did not exceed that been pressed, an array of buttons was designed to be mounted which can be supplied by the Teensy and also from the system on top of the keys where the device is positioned close to the as a whole. Each button draws about 0.25mA of current, so contact each key has with the whippets on the top. To cover for each board the maximum current drawn would be about all 88 keys on the piano, three boards were designed with one 8mA. This is well within the range the Teensy can supply, Teensy 3.6 per board. These Teensys will organize the current therefore the feasibility was passed. state of the buttons, pressed or not pressed, and send them out In the same vein, the microphone feedback system had also via a serial Tx port to a master Teensy. This master Teensy been tested in the previous iteration of the Piano Player MSD gathers the information from the three mounted boards from team, so not much was changed in regards to the design the serial transmission. The representation of the data that is and implementation for this iteration aside from a different being serialized is a one-hot implementation where one button microphone. Since the decision to use Onsets and Frames was corresponds to one key. Each board sends 4 Bytes of data, 32 already determined, no unique feasibility was performed. bits, even if the boards do not actually have 32 buttons in use. The most significant bits are the padding to accommodate the E. Server and Front-end Design varied number of buttons per board. The master Teensy will The server and front-end of the Player Piano design en- send all of the data to the Raspberry Pi in an order that reads compasses the software controls system and user connectivity from left to right as Left board – Middle board – Right board. portion of the project. As an overview, the server is an The Pi uses this information to ideally display for the user instantiation of an Express javascript server that has auxiliary python functions that provide the hardware control scheme. webpage in which a user, connected to the same WIFI as Meanwhile, a single-page-application web framework is uti- the Raspberry Pi that hosts the server, can access the control lized to display options for the user to utilize when using the schema of the Player Piano. Once a user connects, the op- piano. Both of these work in tandem to provide a user with tions are Library, which takes the user to a list of playable designated control of the player piano. songs, Calibration, which automatically calibrates the system 1) Client-Side Functionality: The design of client-side to correct volumes per note, and Record, which allows the functions begins with the existing documentation as described user to skip selecting a song and immediately record playing by previous cycles of work done by previous teams alongside to a MIDI file. As for the Play functionality, when a song reiterations provided by the customer to ensure the desired is selected, the user will have a suite of options available to end product. Relating to what the user is able to accomplish, play and pause music, set the tempo, choose left and right the requirements can be summarized as follows: Ability to handed-ness of a song, and record. record performance to a MIDI file, create a user manual, 2) Server-Side and Controls: To develop the background volume/tempo controls, and general abstract improvements for the client-side operation, the customer requirements first to the playing/training/practice interface. These requirements must be met. From the customer’s requests, the server and provide the customer’s vision to develop the end product. control details can be described as the following: Ability to Of course, the abstracted customer requirements do not record performance as MIDI file, must play any standard provide any information in the actual feature build procedures MIDI arrangement completely autonomously, piano plays the or such items that need to be improved upon. As the project notes typically played by one hand while the user plays is a continuation of previous iterations of work, there is a the notes of the other, and should sound as much like a defined current state on which the build requirements are built human player as possible. These requirements can be noted upon. The client-side of the Player Piano rests upon a single- as generalized and broad considering the total operation of page application web-page built solely on a pure javascript the piano. However, due to the importance of the high-level framework. The team was handed code that substantiated three control scheme and how the server controls these scripts, the main functions: Library(Play), Record, and Calibration. Some beginning of interfacing begins here and serves as the first pages were filled out, while the rest of the features were, major integration point to the rest of the player piano. in the least, skeleton frames. Moreover, a general CSS style was provided by the previous team that would serve as the framework of visual design. With an established project base, the engineering require- ments were developed from the customer’s requests. The new design principles are as follows: Lead-in/Metronome, Intuitive UI, User Manual, and Key Volume/Dynamics. These requirements are immediately followed by respective test plans to designate completion. In relation to the customer requirements, these details encompass not only the requests but the anticipated engineering steps to be undertaken during design. This is seen in the inclusion of a Lead-in/Metronome requirement, which was a specific user request, versus the Intuitive UI requirement, which was not explicitly stated, but is the totality of the final product’s user experience. The feasibility of the client-side application development is reliant on project benchmarking if not outright verified via Fig. 9. UML diagram of UI features - controls interaction not included prototype. The client-side revolves around the general expecta- tion of a well-developed application, not much different than a The customer requirements therefrom are designated into phone app or website. As such, specific features of the UI are engineering requirements that guide the team into specifying related to their accomplished counterpart. As such, feasibility production direction. The specific requirements pertaining to for some features were proven via examples to pre-existing server and controls are as follows: Ability to play any song applications, which refers to the Play piano scroll which was naturally and autonomously, one hand operable, and MIDI benchmarked off of various piano scrolls apps namely Google compatibility. Unlike the loose ends of client-side production, Piano Lab, and the calibration feature, which is related to other engineering the server and controls are straightforward. Play- digital player piano devices. Meanwhile, prototyping paved ing a song naturally is subjective, but autonomously play is the way for feasibility for other features, of which are the measured by a control script being able to play a song with recording to a MIDI file, which was done through Magenta designated accuracy, relating to MIDI play script functionality. Onset and Frames testing. As for One Hand Operable requirement, the final product must With feasibility settled, the final design of the system ultimately perform a piece consisting of “one hand’s worth” was able to be determined as a single-page application style of autonomous play, and do so at a pace in which a human can play alongside. This is measured by a general user feedback The extenders proposed by P20363 work well and allow for scale. Lastly, MIDI compatibility encompasses the foremost adjustability. Implementing the o-ring solution on the outside importance of the player piano is translating and converting of the solenoid housing has reduced the noise made while MIDI files into information that is able to be parsed and activating the solenoids. Though exact measurements were not played. The unit of measure to determine success is simply taken, one can hear more of a dull “thud” with the o-rings as whether or not the data of a MIDI file matches the output. opposed to a metal-on-metal clank. The o-rings were not glued Feasibility for the server and controls scheme follow non- to the housing as proposed by P20363, but they seem to do the measurable standards, much like the previous client-side devel- job just fine placed loosely between the hex nut and housing. opment standards. The ability for the Player Piano to broadcast Placing the spring inside the housing also reduces noise while a server for users to connect to is inherent with no real decreasing fall time. Tests showed that without a spring the restrictions on how many users are allowed to connect, server plungers could become temporarily magnetized and stuck in security, and other accountable details. The primary directive the activated position. But with the spring inside the housing, of the server is to host a webpage for a user to connect to. this issue was not found and the decreased fall time showed Meanwhile, the control scripts are subjected to prototype tests that 16th notes could be played on a single key at nearly 120 and related benchmarking standards in order to prove their beats per minute, but still within the acceptable range. The ability to accomplish their tasks. For example, MIDI file trans- spring of length 0.375” was chosen because it provided enough lation to electrical-system readable information was prototyped force for plunger return, but was not too long so as to restrict and tested on an example PWM board and solenoid rig to the amount the plunger could move. prove functionality. Likewise, the button feedback system was B. Solenoid Electronics/Power System integrated to the Raspberry Pi to ensure that a live feed of information was able to be accomplished. At the point of writing, three boards have been completely Meanwhile with feasibility granted, the finalized design assembled and one partially assembled. The design is shown shows how the developed system plans to provide the user to be working and functional, and able to fire solenoids as with aforementioned controls. A server will be set up where requested. A total of four octaves (48 notes) have been tested the Raspberry Pi is able to relate user commands to scripts that and shown to be operational. Mounting of two of the boards control the electrical components with redundancy safeguards was done, and the last two frames are still being made. and safety limitations. In order to do so, once the server is established via an Express framework, it utilizes python scripts to handle two different main systems, the Server-PWM System (SPS) and the Server-Feedback System (SFS). Respectively, these functions control the solenoids array for playback and the recording for MIDI files and piano scroll visualization.

III.RESULTS AND DISCUSSIONS A. Frame and Solenoid Mechanics At this moment in time, the frame and mechanical parts of the solenoids are in good working order. The frame built Fig. 11. Two control boards mounted on the frame. by previous teams fits in the piano well and allows for the The P20363 team had purchased 6 boards. Only two of mounting of all needed components. Only 86 solenoids (as them were partially soldered, and as a result, four remained opposed to the desired 88, one for each key) are mounted due untouched. After a fair amount of time trying to debug the to a lack of space, however the customer granted permission previous teams board soldering, those two boards were aban- for this to be acceptable (Fig. 10). doned and the remaining four boards were assembled instead. On the 4 boards worked on this iteration, some individual circuits were causing issues. Debugging was conducted, and 78 of the 86 circuits were operable. Testing of the board’s performance focused on the number of notes playable and the dynamics at which those notes are playable. The system has thus far exhibited the ability to play ten notes simultaneously. It also is able to play observable dynamics from pianissimo to fortissimo. Power draw and safety performance of the piano has been observed to be adequate. It does not pose a safety hazard. In the event too much current is drawn, the relevant power Fig. 10. Piano with frame installed. supply will shut off and require a power cycle. Previous teams have determined that the temperature reached by solenoids and other components is too low to pose a fire risk. C. Sustain Pedal The main tests for this subsystem were in regard to the placement of the sustain pedal, the timing with regard to full pedal engagement, as well as the safety systems described above. The sustain pedal requires a 12V input to engage the plunger, and the Raspberry Pi cannot output that much voltage directly. Additionally, the forward/backward controls for the actuator correspond to inverted 12V polarity (+12V for forward, -12V for backward). This necessitates the use of an H-bridge, which is a circuit that lets you control a DC motor with a different magnitude/polarity voltage.

Fig. 13. Top and bottom of button feedback boards

to real-time. The time it takes for the individual Teensy to send data to the master Teensy is only 10ms as defined by Fig. 12. H-bridge wiring diagram. the code. The USB serial communication between the master Teensy and the Raspberry Pi is operating at 9600 baud, or As of this writing, the final aspects of the sustain pedal 9600 bits per second. For 12 bytes to be sent serially, this subsystem are in the works, namely the code for commu- would take another 10ms. The defined criteria was to be under nicating between the Raspberry Pi and the linear actuator, 25ms and according to these calculations, the delta is about and the full incorporation of the H-bridge. Aside from these 20ms therefore proving that the Engineering Requirement is connective aspects, the sustain pedals performance meets all satisfied. For the microphone feedback, the accuracy of the of our requirements, and all tests were successful, yielding microphone based on the placement around the piano was positive results. The communications portion of this system tested to ensure that there would be a minimal amount of will hopefully be completed by the end of the semester. interference from the mechanical noises of the solenoids as D. Feedback System well as from the background. Five positions were tested: in the front, on the left, on the right, in the back, and on the With regard to the button-based real-time feedback sub- underside of the piano. The same chromatic scale was tested system, the prototype boards that the P20363 team acquired through the solenoids for consistency. The table below shows were constructed according to the circuit schematic that was the results of the test where under the piano produced the best designed previously. In its current state, there are only 84 results. buttons that have been soldered on, which is within the margin allowed by the Customer Requirement and therefore TABLE I is satisfactory. The left board is missing a few, will get this MICROPHONE LOCATION ACCURACY number later, and the right board is also missing a few. The boards are able to fit some extra buttons on the sides. The master Teensy board which serializes the data to the Raspberry Pi is currently just floating for testing, the location of that is not yet designed as of this point. Also left to do is properly integrate into the Raspberry Pi by writing a Python script which can read from USB serial the data coming from the master Teensy and then properly handle that for the frontend UI. To verify that this subsystem properly satisfies the related Engineering Requirement, the time it takes for the Raspberry Pi to receive the button data any time a button is pressed was 1) Budget Addendum: The budget for this year’s team was calculated and verified through tests. This was to ensure that $500. The P20363 Team acquired much of the necessary hard- the delay was not too great that it would not be close enough ware and the teams prior to that had acquired the solenoids. Thus, most of the expenditures for this year’s budget focused the solenoid controls, relying on the CC64 MIDI channel to on improving or supplementing additional components. A engage the actuator. Related to this, the H-bridge has not yet dedicated microphone for the project was acquired. About been implemented, and is necessary for getting the sustain $150 was spent repairing and tuning the piano. A detailed pedal up and running with the rest of the piano. Mounting list of expenditures can be found at our confluence page. the linear actuator and its engagement sensor would also be a possible improvement, so that their placement is not IV. RECOMMENDATIONS AND CONCLUSIONS altered in the future, and they perform consistently. As it is, A. Frame and Solenoid Mechanics if the engagement sensor button was removed, the actuator There are some upgrades that P21363 identified but were not could potentially cause damage to the piano. Mounting these able to implement. There is still audible noise caused by the permanently would reduce the risk of damage, and keep actuation of the solenoid, which detracts from the requirement components from moving out of place. that the piano sound as much like a human player as possible. While this noise likely cannot be completely eliminated, there D. Feedback System may be some ways to reduce it beyond the solutions already As of right now, the feedback system is about 75% com- implemented. It was proposed that felt be used where the pleted, 3 out of 4 tests passed and integration remains. While extender meets the piano hammer to dampen any noise there. the boards are mounted onto the piano and the microphone Felt or a softer o-ring may also help reduce noise when the position has been determined, there is still work to be done plunger is deactivated. Another area for improvement comes in on integration with the full software system on the Raspberry that there can currently only be 86 solenoids mounted. There Pi. The real-time system needs the python script which parses is not enough room for the bottom most solenoid, and the top the button data and then somehow displays the current state most key has been removed to make way for the frame. While of the piano keys to the user through the UI. Currently the customer approval was given to only have 86 keys playable, idea is that the piano scroll feature will have the keys at the it would still be desirable to have all 88 automated. For the bottom and whatever keys are currently being pressed will bottom key, rearranging of the solenoids and using a special somehow indicate they are pressed in the UI. An unexpected extender with a wider area at the top could do the trick. The top issue that also came up with the button feedback was the most key likely could be reinstalled if a notch was cut and the sound produced by the buttons clicking. This is a problem solenoid could also be installed with some rearranging. This created by the buttons themselves, perhaps if a future team should be run by the customer first, though. In addition, the could find buttons with no audible click to improve upon this. piano could use some general repairs. Though slightly beyond As for the microphone system, the python script is able to the scope of the project, repairing the piano would be nice for start, pause/play, and stop recording. A .wav file is saved to the final deliverable. the Pi as recording.wav. What remains there is to use the Pi B. Solenoid Electronics/Power System to send the .wav form to the Onsets and Frames website to be transcribed and then download the resultant MIDI to the Currently all four boards have been fully constructed and Pi for replaying, similar to uploading a new song. This fits in installed onto the frame using the 3D printed mounts. 8 circuits with the “Record” feature that is available to the user where on the piano require debugging and potential component the song is recorded and able to be played back by the piano. replacement. In addition, a potential short was noticed in In retrospect, the microphone work was less difficult than the first board, and could require more extensive repair. The previously imagined so that should have been completed by the fuse and 14 AWG power cord have been purchased but not end of MSD II. Getting an earlier start would have mitigated installed. this. The work on the button boards was accurately assessed, Future teams should also consider replacing the existing and by starting in MSD I it is at a state in which integration is solenoid boards with one’s better designed and optimized. the last thing that remains on that subsystem. In conclusion, the Some beneficial features missing include holes for mounting, next steps for a future Computer Engineer on this project is to sizing and spacing of holes for terminal blocks, and additional finish up the integration into the software in conjunction with circuit components to reduce the holding current supplied to the full-stack developer on the team, ideally before making any the solenoids (Such as a holding resistor). Such a modification major improvements to the buttons or microphone handling. could support more notes playable at once. An upgrade to the 36 volt power supply could also be considered. In order for E. Full-Stack Software Development the piano to be placed in an end user environment, the power cord consolidation would need to be a completed step. Software development during this cycle brought together the culmination of several years’ worth of work; however, the de- C. Sustain Pedal sired completion times designated by design plans were found In the event that communications between the Raspberry to be reasonably feasible, but not able to be fully realized. To Pi and the linear actuator are not completed by the end of begin with client-side development, the design scheduling for this semester, that will be the top priority for this system the system is achievable, and despite ambitious goals being of the piano. The code for this will be operating alongside set, can see a successful completion of all desired features. The primary failing of the design scheduling for the client- side web application development was the lack of specific details to accommodate a finalized product. A minimum viable product was configured for the web-application as a whole, but there were no in-depth descriptions of redundancy features, user limitations, etc. As such, it is under recommendation that the web application portion of the design phase branch away from designated multi-disciplinary classwork orientated design and instead utilize software design principles to better capture the scope of the final product. Meanwhile, the server code and associated scripts were well encapsulated by the design processes and development mostly went as planned. The primary stoppage turned out to be an underestimation of the amount of integration testing needed, resulting in the omission of a python web-server framework. Recommendations for these items are to not underestimate the timing required for in- tegration testing, especially with the PWM control boards. The primary recommendation for future software development is to immediately acquaint oneself with the code when beginning the project. Despite the traditional coursework stating not to perform any work/adjustments until design phases are finished, the project had already been thoroughly designed necessitating the engineer waste no time properly detailing tasks, especially if unfamiliar with web application development.

ACKNOWLEDGMENTS Though many hands have contributed to our preparation for and work on the project, our team would like to es- pecially thank the following people for their contributions: Jerry Adamski (Team Guide), Ron Dufort (Customer), Bernie Student (Donor), Dr. Elizabeth DeBartolo (MSD Director), Chris Fisher and MSD Office Staff, RIT Mechanical Engi- neering Department, Previous RIT Player Piano Teams, The Construct, RIT Machine Shop, Daniel Minnick (Piano Tuner), Ben (Raspberry Pi Donor)

REFERENCES Further documentation can be found at our team Confluence page: https://wiki.rit.edu/display/P21363/