piano touch keys ii
play

Piano Touch Keys II P13364 Team Roles Alex Coleman: Project - PowerPoint PPT Presentation

Piano Touch Keys II P13364 Team Roles Alex Coleman: Project Manager Bruce Kynoch: Team Facilitator Ed Mackowiak: Lead Engineer Whitney Zack: Quality/B.O.M./Budget Project Goals Augment a keyboard to allow musical parameters (pitch,


  1. Piano Touch Keys II P13364

  2. Team Roles Alex Coleman: Project Manager Bruce Kynoch: Team Facilitator Ed Mackowiak: Lead Engineer Whitney Zack: Quality/B.O.M./Budget

  3. Project Goals ● Augment a keyboard to allow musical parameters (pitch, timbre, intensity) to be changed while playing with two hands. ● Allow the musician to play in a way that isn't possible on currently available keyboards. ● At least two axes of control, tracking both position and velocity. ● Demonstrate this functionality on a two and a half octave keyboard

  4. The McPherson Multi-Touch Keyboard ● Video of Drexel Solution ● Similar project using capacitive touch ● Accomplishments ○ Bending pitch, vibrato ○ Instrument augmentation ○ Simultaneous three touch on each key ○ Black keys - single vertical axis ○ White keys - dual X/Y axis

  5. Expanding on the McPherson project ● Configurable software for user through Plogue ○ Sound Modification ■ Magnitude ■ Multiple parameters/axes ■ Type ● Velocity controls ○ Provides another method of control beyond X/Y position ● Potential use of Leap Motion technology ● Industry standard MIDI use instead of OSC

  6. Functional Decomposition

  7. Generic System Architecture Supervisor processor - takes in the sound protocol signal and alters it depending on the sensor information. Also using an internal communications protocol, the supervisor processor is polling the input processors for finger location information. PC Sound Editing Suite - takes the sound protocol signal and converts it into an actual sound. Must be able to have scripts written for it to interpret the data we are adding to the signal. Input Processors - Many of the proposed solutions use a sensor per key. The input processor is in charge of taking the data from the sensor, interpreting it so that it is useful, and turning it into serial communication.

  8. Detailed System Architecture

  9. Input Sensor Requirements ● Attachable to a piano keyboard ● Two axes sensing ● 7ms response time ● $100 budget when manufactured (32 keys) ● Does not impair pianist ability to play ● Multi-key sensing

  10. Possible Sensor Concepts ● Capacitive touch sensor ○ PCB with laminate/soldermask ● Infrared touch technologies ○ Blackberry sensor ● Resistive touch sensor ○ Carbon Paint ● Camera from above the keys ○ Leap motion ○ Misc. Optical sensor

  11. Lower number is better

  12. Input Processor Requirements ● Handle capacitive touch inputs. ● Capable of calculating ○ Velocity ○ Location ○ Potentially area ● Communicate to master processor. ○ Protocol - Preferably I 2 C ● Size ○ Can be fit or potentially built into keyboard ○ Layout can be mapped consistently onto PCB interconnect

  13. Lowest number is best

  14. Internal Communication Protocol Requirements ● Must be bus based, since scaling to large numbers of keys shouldn't require more processor GPIO pins ● Able to service all nodes within timing requirements

  15. I 2 C Timing 10-bit address 8-bit X location 8-bit Y location = 26 bits per key, per refresh * 2.5 usec per bit = 65 usec per key, per refresh * 32 keys = 2.08 msec worst-case bus delay In reality, closer to 3-3.5 msec

  16. Supervisor Processor Requirements ● Interface with PC ○ MIDI ○ Possibly over USB and HID ● Communicate with input processors ○ I 2 C ○ 400 kHz ○ ~32 input processors, individually addressed ● Interpret data from input processors and output modified keypress data

  17. Plogue v. MAX ● Some software is needed to generate sound from the MIDI signals and to apply pitch bending and other tonal effects ● The potential customer (Don Slepian) is more familiar with Plogue ● Plogue License is less expensive than MAX ● The Plogue code can easily be shared with Don

  18. Risk Assessment (High Importance) ● Project delays due to end-of-quarter workload/technical problems ○ Weekly meetings and progress reports; creating a buffer zone for deadlines. ● Delays in parts/PCBs ○ Designs will be completed early and parts will be ordered through familiar companies. ● Plogue demo license insufficient ○ May impact budget; funds will be reserved for the license. ● Accuracy/response time problems with touch ○ A proof of concept for capacitive touch will be done before MSD2; etched boards will be used for multiple prototypes

  19. Risk Assessment (Low Importance) ● Errors/mistakes in PCB ○ Use a reputable manufacturer; review PCB design with other team members/outside consultant. ● I2C or USB bandwidth/response insufficient ○ Estimations predict that this is unlikely; another I2C bus is available on the supervising controller.

  20. Schedule MSD1 ● Week 7 ○ PCB ■ Prototype layout etched ○ Microcontroller ■ Various comparison tests ■ Chose final microcontroller for DDR ○ Touch Sensor ■ Acquire prototype chips for testing with PCB ● Week 8 ○ Prototype testing ■ Hardware comparisons and revisions ○ Draft of DDR (Schedule DDR) ○ Review with guide

  21. Schedule MSD1 (cont.) ● Week 9 ○ Present DDR ○ B.O.M. and Order ■ PCB layout order from manufacturer ■ Touch sensor layout order from manufacturer ● Week 10 ○ Revisions of DDR ○ Summary of B.O.M. ○ MSD2 Schedule

Recommend


More recommend