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

piano touch keys ii
SMART_READER_LITE
LIVE PREVIEW

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,


slide-1
SLIDE 1

Piano Touch Keys II

P13364

slide-2
SLIDE 2

Team Roles

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

slide-3
SLIDE 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

slide-4
SLIDE 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

slide-5
SLIDE 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
slide-6
SLIDE 6

Functional Decomposition

slide-7
SLIDE 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.

slide-8
SLIDE 8

Detailed System Architecture

slide-9
SLIDE 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
slide-10
SLIDE 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

slide-11
SLIDE 11
slide-12
SLIDE 12

Lower number is better

slide-13
SLIDE 13

Input Processor Requirements

  • Handle capacitive touch inputs.
  • Capable of calculating

○ Velocity ○ Location ○ Potentially area

  • Communicate to master processor.

○ Protocol - Preferably I2C

  • Size

○ Can be fit or potentially built into keyboard ○ Layout can be mapped consistently onto PCB interconnect

slide-14
SLIDE 14
slide-15
SLIDE 15

Lowest number is best

slide-16
SLIDE 16

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

slide-17
SLIDE 17
slide-18
SLIDE 18

I2C 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

slide-19
SLIDE 19

Supervisor Processor Requirements

  • Interface with PC

○ MIDI ○ Possibly over USB and HID

  • Communicate with input processors

○ I2C ○ 400 kHz ○ ~32 input processors, individually addressed

  • Interpret data from input processors and
  • utput modified keypress data
slide-20
SLIDE 20
slide-21
SLIDE 21

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

slide-22
SLIDE 22

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

  • rdered 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

slide-23
SLIDE 23

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.

slide-24
SLIDE 24

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

slide-25
SLIDE 25

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