university of southampton faculty of engineering...

UNIVERSITY OF SOUTHAMPTON

Faculty of Engineering and Applied Science

A group design project report submitted for the award of

Master of Engineering

Supervisor: Dr Steve GunnExaminer: Dr Matthew Wright

GDP 7

Electronic Timpani

by Stephen Emsen, Christopher Heal,Richard Sunderland, Robin Willis

April 26, 2002

http://www.soton.ac.uk

http://www.engineering.soton.ac.uk

mailto:[email protected]




UNIVERSITY OF SOUTHAMPTON

ABSTRACT

FACULTY OF ENGINEERING AND APPLIED SCIENCE

A group design project report submitted for the award of Master of Engineering

by Stephen Emsen, Christopher Heal,Richard Sunderland, Robin Willis

The timpani is a large orchestral instrument that lends weight and substance to music.The timpani must be large to produce these low frequencies, but its size renders itawkward, expensive and difficult to transport. A training instrument could be used tolearn the skills of timpani playing, without requiring access to a set of classical timpani.A design for an electronic timpani is here proposed to meet this requirement.

The system described includes a bespoke ‘pad’ that senses the player’s motions, anelectronic circuit for initial signal conditioning and a software program that emulatesthe output sound of a timpani based on these inputs. The algorithms required for inputprocessing are detailed, along with several areas for their future development. Duringthe course of the project a series of timpani recordings was collected. This then formedthe basis of the sound generation algorithms. It is likely that any future projects willwish to improve and expand this collection of recordings.

A working prototype has been produced which can be used as a platform for furtherdevelopment. This project may eventually evolve into a commercially viable product.

http://www.soton.ac.uk

http://www.engineering.soton.ac.uk





Contents

Acknowledgements iv

1 Introduction 11.1 Project Brief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Introduction to the Timpani . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3.1 History and Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3.2 Timpani Constitution . . . . . . . . . . . . . . . . . . . . . . . . . 31.3.3 Playing a Timpani . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Ambiguous Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Research into the Sound of Timpani 62.1 Psychoacoustics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2 Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.3 Harmonics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Timpani Acoustics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.1 Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.2 Radiation and Decay . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Physical Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 Quantifying a Strike . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Initial System Development 153.1 Brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2 System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1 Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.2 Required Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.3 Location of Processing . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 Proposed System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.4 System Division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Specification 194.1 General attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2 Playing area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.4 Sound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Hardware 22

ii

CONTENTS iii

5.1 Sensors Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.1.1 Camera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.1.2 Electronic Drum Pads . . . . . . . . . . . . . . . . . . . . . . . . . 265.1.3 Resistive Foam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.1.4 Hall Effect Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.1.5 Microphone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.1.6 Piezoelectric Transducers . . . . . . . . . . . . . . . . . . . . . . . 295.1.7 Strain Gauge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2 Sensor Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.2.1 Hardware Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 335.2.2 Sensor Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.2.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.2.4 Electrical Characteristics . . . . . . . . . . . . . . . . . . . . . . . 355.2.5 Use of Piezoelectric Transducers for Damping . . . . . . . . . . . 36

5.3 Drum Plate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.4 Signal Conditioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.4.1 Sensor Output Amplitude Adjustment . . . . . . . . . . . . . . . . 375.4.2 Op-amp Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.4.3 Signal Level Shift . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.4.4 Pedal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.5 Digital Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.5.1 Choice of Communication Systems . . . . . . . . . . . . . . . . . . 395.5.2 Selection of Processing Components . . . . . . . . . . . . . . . . . 405.5.3 Use of External ADCs . . . . . . . . . . . . . . . . . . . . . . . . . 405.5.4 PIC Code Development . . . . . . . . . . . . . . . . . . . . . . . . 425.5.5 Serial Communication Voltage Levels . . . . . . . . . . . . . . . . . 425.5.6 Format of PIC-PC RS-232 Communication . . . . . . . . . . . . . 43

5.6 Noise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.7 Development Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6 Software System Design and Implementation 456.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.2 Platform Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.2.1 Processing Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 466.2.2 Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.2.3 Sound Programming API (Application Programming Interface) . . 476.2.4 Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.3 Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.3.1 Modularisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.3.2 Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.3.3 Concurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.3.4 Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.4 Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.5 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.6 POSIX Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.6.1 What is a thread? . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

CONTENTS iv

6.6.2 Why are threads needed? . . . . . . . . . . . . . . . . . . . . . . . 506.6.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.6.4 Exiting the Program . . . . . . . . . . . . . . . . . . . . . . . . . . 516.6.5 Future Alterations . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.7 Program Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.7.1 Initialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.7.2 When a Strike Happens . . . . . . . . . . . . . . . . . . . . . . . . 526.7.3 Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.8 Software Future Developments . . . . . . . . . . . . . . . . . . . . . . . . 546.8.1 Extension to Multiple Timpani . . . . . . . . . . . . . . . . . . . . 546.8.2 Complex Time-Varying Modelling . . . . . . . . . . . . . . . . . . 55

7 Input Processing 567.1 Accessing Serial Port Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.1.1 POSIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577.1.2 Processing Requirements Issues . . . . . . . . . . . . . . . . . . . . 577.1.3 Framework of Serial Port Software . . . . . . . . . . . . . . . . . . 577.1.4 Interpretation of Serial Data . . . . . . . . . . . . . . . . . . . . . 58

7.2 Input Processing Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 587.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.2.2 Framework of Input Processing Software . . . . . . . . . . . . . . . 597.2.3 Buffering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597.2.4 Noise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607.2.5 Zero Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617.2.6 Finding the Noise Threshold and the Zero Point . . . . . . . . . . 617.2.7 Hit Strength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627.2.8 Peak Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627.2.9 Determining Radial Distance . . . . . . . . . . . . . . . . . . . . . 647.2.10 Ringing Effects and Bouncing of Pad . . . . . . . . . . . . . . . . . 687.2.11 Damping Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . 687.2.12 Trade-off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707.2.13 Main Structure of Software . . . . . . . . . . . . . . . . . . . . . . 707.2.14 Interfacing with the Sound Generation . . . . . . . . . . . . . . . . 72

7.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.3.1 Digital Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.3.2 Machine Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . 737.3.3 Improved Peak Detection . . . . . . . . . . . . . . . . . . . . . . . 747.3.4 Improved Hardware Implementations . . . . . . . . . . . . . . . . . 74

8 Sound Generation 768.1 Anechoic Chamber Recordings . . . . . . . . . . . . . . . . . . . . . . . . 77

8.1.1 Purpose of Experiment . . . . . . . . . . . . . . . . . . . . . . . . 778.1.2 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778.1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

8.2 Wavetable Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838.3 Pitch Shifting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

8.3.1 Zero Order Hold / Linear Interpolator . . . . . . . . . . . . . . . . 85

CONTENTS v

8.3.2 Looping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 868.3.3 Waveform Based Pitch Shifter . . . . . . . . . . . . . . . . . . . . 868.3.4 Separate Source/Filter Pitch Shifting . . . . . . . . . . . . . . . . 86

8.4 Data Driven Modelling Approach . . . . . . . . . . . . . . . . . . . . . . . 898.4.1 Principal Component Analysis . . . . . . . . . . . . . . . . . . . . 908.4.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

8.5 Dataspace Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918.5.1 File Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918.5.2 Clipping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928.5.3 Noise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928.5.4 Frequency of Recordings . . . . . . . . . . . . . . . . . . . . . . . . 928.5.5 Hit Strength of Recording . . . . . . . . . . . . . . . . . . . . . . . 938.5.6 Trimming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968.5.7 Tailing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978.5.8 Forming the Dataspace . . . . . . . . . . . . . . . . . . . . . . . . 98

8.6 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988.6.1 Recording Generation . . . . . . . . . . . . . . . . . . . . . . . . . 988.6.2 Frequency Interpolation . . . . . . . . . . . . . . . . . . . . . . . . 988.6.3 Hit Strength Interpolation . . . . . . . . . . . . . . . . . . . . . . . 100

8.7 Damping and Glissando . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018.7.1 Glissando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018.7.2 Damping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

8.8 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038.8.1 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038.8.2 Global Data Structures . . . . . . . . . . . . . . . . . . . . . . . . 1038.8.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

9 Concise System Overview 1059.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

9.1.1 Drum Pad and Sensor Assemblies . . . . . . . . . . . . . . . . . . 1079.1.2 Signal Conditioning . . . . . . . . . . . . . . . . . . . . . . . . . . 1079.1.3 Digital Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

9.2 Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099.2.1 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099.2.2 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099.2.3 Threading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

9.3 Input Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119.3.2 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

9.4 Dataspace Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1129.4.1 Normalising the Dataspace Variables . . . . . . . . . . . . . . . . . 113

9.5 Sound Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1149.5.1 Sound Generation Module . . . . . . . . . . . . . . . . . . . . . . . 1149.5.2 Channel Filter Module . . . . . . . . . . . . . . . . . . . . . . . . . 114

10 Project Management 11610.1 Team Task Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

CONTENTS vi

10.2 Team Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11810.3 Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11810.4 Laboratory Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11810.5 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

10.5.1 Group Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11910.5.2 Formal Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

10.6 Timpani Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11910.7 Timpani Player Availability . . . . . . . . . . . . . . . . . . . . . . . . . . 11910.8 Breadth vs Depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12010.9 Role Adaption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12010.10Software Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

11 Recommendations for Future Work 121

12 Conclusions 12412.1 Success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12512.2 Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12512.3 Input Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12512.4 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12512.5 Product Viability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Bibliography 127

Glossary 130

A Investigation of Clavia Ddrums 1

B Table of Authorship 4

C Time Planning 6

D Software Listings 7D.1 timpani.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7D.2 PIC program(timp8.c) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15D.3 Matlab Prototype Sound Generation Modelling . . . . . . . . . . . . . . . 18

E Hardware Circuit Diagram 21

F Final Budget Breakdown 23

G Initial Idea Sketches 25

H Timpani Photographs 29

I Software Packages Used 32

J M-File index 33

K CD Contents 35

L Recording Index 37

List of Figures

1.1 A Premier Concert Timpani . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Onset and offset phases of different musical instruments . . . . . . . . . . 82.2 Modes of an Ideal Circular Membrane . . . . . . . . . . . . . . . . . . . . 102.3 Wrinkling of Membrane . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Radiation from different Modes . . . . . . . . . . . . . . . . . . . . . . . . 112.5 Finite Element Simulation Results . . . . . . . . . . . . . . . . . . . . . . 13

5.1 Sensor assembly between drum plate and base plate . . . . . . . . . . . . 345.2 Support layers deform piezoelectric transducer when struck . . . . . . . . 345.3 Configuration of the sensor assemblies on the underside of the drum plate 355.4 Operational amplifier connected to function as a voltage follower, or buffer 375.5 Level shift required to meet input voltage range of ADC . . . . . . . . . . 385.6 PIC switches all analogue channels to a single ADC . . . . . . . . . . . . 415.7 Potential solution: External analogue sample-and-hold . . . . . . . . . . . 415.8 Preferred solution: External analogue-to-digital converters . . . . . . . . . 415.9 Voltage levels of serial communication for TTL/CMOS and RS-232 . . . . 42

6.1 Program Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.2 Program Break Down By Thread . . . . . . . . . . . . . . . . . . . . . . . 526.3 Wave Table Playback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.1 State transition diagram of serial program . . . . . . . . . . . . . . . . . . 597.2 4-Point Running Averaging Filter . . . . . . . . . . . . . . . . . . . . . . . 607.3 Plot of the magnitude of the frequency response for a 5-point running

averaging filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617.4 Strike profile on drum plate . . . . . . . . . . . . . . . . . . . . . . . . . . 637.5 Peak Detection Using a Buffer Length of 7 . . . . . . . . . . . . . . . . . . 657.6 Position finding using vectorial representation . . . . . . . . . . . . . . . . 667.7 Invalid position regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677.8 Angular representation of distance between sensors . . . . . . . . . . . . . 677.9 Sensor profile of damping . . . . . . . . . . . . . . . . . . . . . . . . . . . 697.10 Input Processing Program Structure and Operation . . . . . . . . . . . . . 717.11 Mechanism for dropping a ball from a specific height at a certain location

on the pad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

8.1 Equipment Set-up in Anechoic Chamber . . . . . . . . . . . . . . . . . . . 788.2 Premier Concert Timpani with strike position marked . . . . . . . . . . . 808.3 Wavetable Envelope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

vii

LIST OF FIGURES viii

8.4 Waveform from a Zero Order Hold Interpolator . . . . . . . . . . . . . . . 888.5 Pitch Shifting using a Loop Array . . . . . . . . . . . . . . . . . . . . . . 888.6 Example of mode lines found . . . . . . . . . . . . . . . . . . . . . . . . . 938.7 Spectogram of a centre-hit . . . . . . . . . . . . . . . . . . . . . . . . . . . 948.8 Linear correlation between Position and ‘Hit Strength’ . . . . . . . . . . . 958.9 Corrected value vs position. ‘Position 4’ value lies outside expected range 968.10 Tailing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978.11 Linear Resampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 998.12 Spectogram of strike at ‘Position 4’ . . . . . . . . . . . . . . . . . . . . . . 1008.13 Pitch shifting in channel filter . . . . . . . . . . . . . . . . . . . . . . . . . 102

9.1 Overview of electronic timpani system . . . . . . . . . . . . . . . . . . . . 106

A.1 A Clavia Ddrum Pad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3A.2 Output from Ddrum Pad . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

C.1 Project Time Plan Gantt Chart . . . . . . . . . . . . . . . . . . . . . . . . 6

E.1 Circuit diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

G.1 Separate Pads, but One Main Processor . . . . . . . . . . . . . . . . . . . 25G.2 Intertial Measurement of Mallet Head . . . . . . . . . . . . . . . . . . . . 26G.3 Resitive Foam on Ring-Dot Substrate . . . . . . . . . . . . . . . . . . . . 26G.4 Concentric Rubber Rings, with Individual Pressure Sensor . . . . . . . . . 27G.5 Mock Skin with Microphone Array . . . . . . . . . . . . . . . . . . . . . . 27G.6 Camera Based Viewing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27G.7 Rigid Plate Supported on Strain Gauges . . . . . . . . . . . . . . . . . . . 28G.8 Fluid Bath, With Sensor “Hairs” . . . . . . . . . . . . . . . . . . . . . . . 28G.9 Completely Virtual Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 28

H.1 Concert Timpani at the Mayflower Theatre, Southampton . . . . . . . . . 30H.2 Timpani Experiment in the Anechoic Chamber . . . . . . . . . . . . . . . 31

Acknowledgements

The team would like to express their gratitude to the following for their invaluable help:

Mr John Abendstern, timpanist with the Welsh National Opera Orchestra, for initi-ating and supporting the project, and for his generosity and encouragementDr Steve Gunn, for initiating and supervising the project, providing technical assis-tance and guidanceDr Christine Shadle for helping supervise the project and the generous provision oflaboratory spaceDr Matthew Wright for providing invaluable comments and criticism from an acous-tics perspectiveDr John Fithyan for allowing access to the ISVR anechoic chamberDr Keith Holland for help with, and use of, recording equipmentMr Rob Stansbridge for the loan of the sound level meterMrs Ros Austin for ordering the PC components

ix

Chapter 1

Introduction

1

Chapter 1 Introduction 2

1.1 Project Brief

“Timpani are the most important orchestral percussion instruments. They play a centralrole in the orchestra because they underline important chords. However, they are largeand expensive items. The goal of this project is a challenging but interesting one: todesign and build an electronic timpani that is portable, cheap and that reproduces thefidelity of a classical timpani. Since the unit could be used for teaching, it shouldimitate a classical timpani by producing sounds when struck with a mallet (the soundwill depend upon the region struck) and allow for damping when a hand is applied toit. The project would be undertaken with John Abendstern, principal timpanist of theWelsh National Opera Orchestra.” (33)

1.2 Objectives

There are several different inputs that the electronic timpani system should respond to.These inputs were prioritised, in consultation with our sponsor and supervisors.

1. Strike strength

2. Pitch pedal position

3. Radial strike position

4. Damping

5. Glissando

6. Timpani type

7. Mallet type

For a useful training instrument at least the first four of the inputs must be included.The project will therefore attempt to design and implement a prototype that can respondto the first four, and create a reasonable timpani sound in real-time.

1.3 Introduction to the Timpani

1.3.1 History and Role

The timpani, also called ‘kettledrum’, was the first drum to be used in the orchestra over300 years ago. The instrument is capable of a wide range of effects, from a low rumble to


Figure 1.1: A Premier Concert Timpani

resounding and powerful drumbeats. It can emphasise or add a crucial dramatic elementto the melody. The timpani is therefore the most important percussion instrument ofthe orchestra.

1.3.2 Timpani Constitution

The timpani normally consists of a large copper bowl with a drumhead made of calfskinor plastic stretched across the top. When struck with mallets of different compositionand hardness, the timpani produces a specific pitch that is determined by the drum’ssize. Most orchestras use four or five timpani of varying sizes, from 16 inches to 32 inches.The pitch is controlled by tightening the drumhead with a mechanical foot-pedal. Theinstrument is fine tuned by adjusting the tension of the drum head with a set screwsarranged around the edge of the drum skin.

1.3.3 Playing a Timpani

The timpani is a highly flexible percussion instrument. It is most commonly playedwith two mallets, one in each of the player’s hands. Varying the characteristics of the


strike can produce a wide range of effects. Due to the dynamics of the skin, and theinteraction with the outer shell, the sound produced by the timpani is strongly affectedby the position and strength of the strikes. A very common form of playing is a ‘roll’,which entails fast consecutive strikes on the timpani head.

When necessary, the player attenuates the sound prematurely by damping the timpani’sdrum head, either by placing a finger or the whole hand gently on the drum skin. Again,changing the way damping is performed modifies the impact it has on the note.

Most timpani incorporate a mechanical pedal that changes the pitch of the sound. Thepedal alters the tension of the membrane in a range of approximately 3:1, which corre-sponds to a musical sixth. The player can judge the position of the pedal by looking ata tuning gauge mounted on the side of the timpani. If the pedal position is adjustedwhilst a note is still ‘ringing’, then a ‘glissando’ (or sliding note) will be generated.

The timpanist is required to have a good musical ear, as the drums may need to betuned several times and to different pitches during a performance. Two or three notes(depending on the number of drums) are named at the beginning of the score and theseare the notes that the player must initially tune to.

Finally, some orchestral musical pieces require quite obscure forms of timpani playing,such as hits on the shell of the timpani.


1.4 Ambiguous Terms

Throughout the report, due to its inherent ambiguity, the term ‘sample’ been avoided,The following terms have been used:

• Recording: Recording of the sound created following a single strike of the tim-pani, i.e. there is a recording of a strike for each ‘frequency’, ‘position’ and ‘hitstrength’

• Waveform: A waveform refers to any collection of datapoints that does notdirectly come from a recoding, i.e. has been generated in some way.

• Datapoint: A datapoint is the information stored at the instance of sampling arecording, i.e. a recording is made up of a sequence of datapoints created at thesampling frequency.

For further definitions and abbreviations see the Glossary (2)

Chapter 2

Research into the Sound of

Timpani

Before the task of creating an electronic timpani can be approached, it is beneficial tounderstand not only the way in which it is played but also how the distinctive sound ofthe timpani is formed.

6

Chapter 2 Research into the Sound of Timpani 7

Musician Engineer ElectronicTimpani

Pitch Frequency of Fundamental YesTimbre Spectral Content Yes

Dynamic Outline Envelope YesArticulation ” Yes

Duration ” YesVibrato Frequency Modulation No

Portamento (note to note) Slew rate, Freq Staircase YesTremolo Amplitude Modulation No

Bow scrapes, Noise Content Nature NoHand Attacks ” No

Breath Sound etc ” No

Table 2.1: Musican’s and Engineer’s Term Comparison

This project spans both the engineering and musical worlds and as such it is importantthat commonly used terms are mutually comprehensible. Table 2.1 compares someimportant terms.

2.1 Psychoacoustics

This section explores some useful background information into the psychoacoustics ofmusical instruments.

2.1.1 Attack

The attack of a note includes both the initial transients and onset of harmonics formedas an instrument is struck or excited in some way. Many of these initial harmonics, andthe frequency contribution formed from the initial transients, will quickly decay, leavingthe ‘ringing’ section of the note. The brain primarily uses the attack part of the noteto identify an instrument. Listeners cannot reliably identify musical instruments whenthe onset and offset phases of the harmonics are removed. The attack contains a highportion of information which gives the instrument its characteristic sound. Experimentshave been used to demonstrate this, using the phase information from one instrument,such as a clarinet, to replace the phase information from another instrument, such as asaxophone. Listening tests showed that the majority of people identified the instrumentas the one which the phase information had been taken from. Fig 2.1 shows the onsetand offset phases several different instruments (28).


Figure 2.1: Onset and offset phases of different musical instruments

2.1.2 Latency

No direct measure of the delay acceptable to a musician, between playing a note onan electronic instrument and hearing a sound produced could be found. However arange of 20 to 30ms is usually associated with the human auditory system. Similarly,it is documented that the same value is considered reasonable for the time between twosimilar sounds before one is masked by the other.


Mode: 11 21 31 41 51Freq. Ratio: 1 1.5 2 2.44 ( 2.5) 2.9 ( 3)

Table 2.2: Mode vs. Frequency Ratio

2.1.3 Harmonics

Only the first five to seven harmonics of the fundamental note can be resolved separatelyby the hearing system (i.e. if one of these harmonics were to be removed or altered itwould be clearly audible). For higher harmonics this is not the case. The pitch ofthe instrument is governed by the relationship between these harmonics or ‘modes’. Forpercussive instruments these modes form non-harmonic ratios which give a characteristicpercussive sound where it is more difficult to determine the pitch. The timpani soundlies between a tonal and percussive instrument, with a definite sense of pitch portrayed.

2.2 Timpani Acoustics

Exploration into previous research on the acoustics of timpani is considered in thissection.

2.2.1 Modes

It is important to remember that a timpani drum is usually struck in a region aroundone quarter of the way across the membrane, rather than in the centre. It is well knownamongst timpanists that a ‘dull’ sound is created when the timpani is struck in the centreof the drum. It is for this reason that the principle ‘note’ of the timpani corresponds tothe oscillating ‘11’ mode (fig. 2.2) rather than the ‘01’ mode. This is often known asthe ‘missing fundamental’. Also, other modes form harmonic ratios of this mode. Forexample, the ‘21’ mode was a perfect fifth; the ‘31’ a major seventh and the ‘12’ modeprecisely one octave higher. More recently it was shown that the ‘n1’ modes formedprominent harmonic partials (42) as shown in table 2.2. The inharmonic ratios and theyhave been shifted up in frequency to form harmonic ratios. The following reasons forthe shifting of modes into harmonic ratios have been proposed (40):

1. Air loading of the membrane lowers the frequency of the modes below 350Hz.

2. Modes of air enclosed within the kettle interact with the membrane, with asimilar shape.

3. The bending stiffness of the membrane raises the frequency of the higher har-monics.


Figure 2.2: Modes of an Ideal Circular Membrane

4. High shear stiffness of the membrane resists wrinkling. (fig. 2.3)

The first of these probably has the highest significance, whereas the latter three arelikely to have more effect on the note decay. It might be concluded that the shape ofthe timpani is optimum, fine tuning the prominent partials into harmonic ratios, due tothe interaction of the enclosed modes of air within the kettle, however it is suspectedthat this is not a strong effect.

Figure 2.3: Wrinkling of Membrane

2.2.2 Radiation and Decay

The most significant loss in the timpani membrane is due to the radiation of sound to theair (over mechanical loss in membrane, viscothermal loss in confined air and mechanicalloss in walls). A baffled membrane vibrating in its ‘01’ mode radiates its energy far more


Mode Ideal fmn/f11 Experimental fmn/f11

01 0.63 0.8711 1.00 1.0021 1.34 1.5102 1.44 1.6831 1.66 1.9912 1.83 2.3441 1.98 2.4622 2.20 2.7451 2.29 2.9332 2.55 3.2861 2.61 3.3813 2.66 3.3842 2.89 3.80

Table 2.3: Calculated and Experimental modal ratios

quickly than other modes and therefore decays rapidly. The ‘0n’ modes are excited bya centre hit which generally produce an unpleasant sound. The ‘01’ mode radiateswith monopole radiation as it is enclosed within the kettle (fig. 2.4). In the absenceof the kettle this would become an unbaffled source and radiate with dipole radiationfrom either side of the membrane. Other modes will radiate with dipole or quadrapoleradiation and as such the energy from these modes will be radiated less rapidly (40).

Figure 2.4: Radiation from different Modes

For this reason we know that a centre hit on the timpani will damp quickly, as it excitesthe ‘0n’ modes, which partly accounts for the ‘dull thump’ sound produced. The otherreason for the less tonal nature of a centre hit, is that the ‘0n’ modes excited are not intuned harmonic ratios.

2.3 Physical Modelling

Good numerical models for the timpani already exist (1), detailing the evolution withtime a timpani’s sound and vibration. In essence, the non-linear interaction between


Modes Theoretical Simulated Relative Error(mn) fmn (Hz) fmn (Hz) %

01 139.1 139.3 0.1811 221.6 222.0 0.1721 297.0 297.3 0.1002 319.3 319.3 0.0231 369.0 369.3 0.0912 405.8 405.7 0.0241 438.9 439.0 0.0322 486.8 486.7 0.0303 500.5 500.0 0.1051 507.3 507.0 0.0632 564.6 564.0 0.1061 574.7 574.3 0.0642 639.9 640.3 0.0623 672.1 670.3 0.2604 682.0 679.7 0.34

Table 2.4: Comparison of theoretical and simulated eigenfrequencies

mallet and membrane can be considered, taking into account the contribution fromvarious damping parameters, including:

• Membrane material

• Boundary absorption

• Losses in felt

• Acoustic radiation

The motion of the membrane is then coupled with both the external and internal soundfield, so that the acoustic pressure field can be calculated for a given point in space. Thissimulation uses three-dimensional finite element modelling to validate results, producingtime-domain snap-shots of the membrane displacement, pressure fields and the pressurejump across the boundary (fig. 2.5). Results are surprisingly accurate as can be seenby comparing theoretical and simulated modes (table 2.4). The model could easily beused to help separate parameters and determine geometrical and physical parameters.Potential applications include optimisation of timpani cavity volume.

The initial hit can be seen at the onset by the negative displacement (shown in green),followed by propagation of the transverse bending wave. In the final diagram a positivedisplacement is shown as the membrane pushes the mallet away from the drum. Thepresence of a guided wave in the acoustic pressure field is also of interest, as it pre-cedes the elastic wave front and is travelling at three times the speed (compare (b) indiagrams).


(a) Simulation of membrane displacement during first 10ms

(b) Simulation of acoustic pressure field during first 10ms

(c) Simulation of pressure jump across boundary during first 10ms

Figure 2.5: Finite Element Simulation Results


2.4 Quantifying a Strike

The numerical modelling paper (1) considers a strike from the initial point of contactregardless of how the mallet is set in motion. However this model neglects the variationof contact time and the hysteric cycle of relaxation in the felt and the stick. Other sourcesuse the same method to measure the input to the timpani from the mallet (47). Thesemethods consist of measuring the force and acceleration with an impedance head. (Animpedance head is simply a force gauge and accelerometer in one package.) The forceand acceleration yield a similar shape and the effective mass can therefore be calculatedfrom the transfer function of these signals on a dual channel FFT analyser. Researchhas found the effective mass to be 20% higher than the static mass of the mallet head,which is likely to be due to the inertia of the mallet handle and player’s arm. The forceis obtained from the acceleration of the mallet, using an accelerometer on the mallet,and the previously calculated effective mass.

Depending upon the modelling approach used, it may be necessary to be able to quantifya hit in this way. Brief experiments were made to investigate this but were not continuedas it had a low priority.

Chapter 3

Initial System Development

At the outset it was important to explore the overall system structure. This sectionoutlines how and why the current system was chosen.

15

Chapter 3 Initial System Development 16

3.1 Brainstorming

During the course of several meetings a range of ideas were generated and researched.Initially, brainstorming sessions were used, with all participants’ ideas written on a whiteboard. This helped stimulate discussion and highlight areas where decisions were to bemade. A zero-criticism approach to idea generation was used to foster a fast and flowingspirit of creative interaction. At the end of each brainstorming session, group memberswere assigned areas to research before the next meeting.

3.2 System Design

3.2.1 Inputs

Inputs have to be received from the timpani player and passed to a sound generatorat some point in the process. There are several well-established protocols that allowdigital musical instruments to interact with other hardware. The most popular of theseis Musical Instrument Digital Interface (MIDI), which has played a pivotal role in thedevelopment of digital music. It offers a limited amount of control, but has the advantagethat a large range of existing hardware and components can be used to develop and testit. An alternative protocol, ZIPI, is much more flexible. This provides a method ofcommunicating a greater range of musical inputs than MIDI, such as vibrato or positionof percussive strikes. It also allows control of single notes rather than just whole channels.It is unfortunately quite rare.

Another approach would be to send readings from the input devices directly to theprocessing unit, via some from of digital to analogue conversion and communication. Itshould be remembered that this system is likely to have several separate input devicescorresponding to each timpani. Consequently, any complex hardware that is requiredwould have to be repeated for each. The possibility of “daisy chaining” the input devices,to cut down on the amount of cabling required, should be considered. It may even bepossible to use some form of wireless communication.

3.2.2 Required Outputs

There could be several ways of outputting from the system.

• Direct output from each input device (or ‘timpani’) via internal loudspeaker andamplifiers.

• Analogue output via headphone/line-out connected to external audio equipment.


• Digital output may be useful for recording or further external processing.

• If any form of analogue to digital conversion is used, then the sampling rate mustbe specified.

In addition to all of these, the number of output channels must be selected: either mono,stereo or some form of surround sound.

3.2.3 Location of Processing

There are three main levels at which conversion to output signal could happen:

• In individual input devicesIt would be possible to put separate sound generation units in each input unit anduse a simple analogue channel combination to create the output. This would beanalogous to giving each timpani a separate microphone.

• Separate hit detection and generationIt would be possible to separate hit detection and sound generation using oneof the symbolic digital music communication protocols (like MIDI or ZIPI). Thiswould require each input device to handle input processing.

• All processing in PC or dedicated hardwareAll the input devices scan their inputs, convert them to digital values and forwardthem to a central processing unit. This unit would then do all the work scanningthe digital inputs and generating appropriate output sounds.

3.3 Proposed System

It is clear that the prototype system should closely resemble a potential final solution,but must also serve as a development platform. It is therefore proposed that all thecomplex processing is performed in a central processing unit (i.e. desktop PC), to whichthe external hardware supplies data via some standard form of communication. If thissystem was developed into a commercial product, symbolic communication and integra-tion with protocols like ZIPI may be practical. This is however considered impracticalat this stage.

This system will therefore consist of a single external hardware device that capturesuser inputs and passes this information to a desktop PC via a standard input port. ThePC software will then use this data to generate a waveform, which will be outputtedthrough a sound card.


Low frequency sound is non-directional; it is difficult for the human auditory system todetermine the direction from which the sound is coming. From an audience’s perspective,a mono source at the position of the timpani would be as effective as a stereo source.It may be considered that the timpani player is experiencing a stereo effect due to thepositioning of several timpani, but for the purposes of development this may be ignored.Digital to analogue output will therefore be mono at 44100Hz. (This sample rate allowsfor higher frequency components than the electronic timpani may need to produce, butis the standard rate for CDs and is therefore available on most sound output hardware.)

3.4 System Division

It is clear that the proposed system divides into two parallel components, namely hard-ware and software. Although these systems interact they can largely be developedindependently. The team therefore split into two task groups to tackle these areas. Thefollowing chapters detail the development process.

Chapter 4

Specification

The specification for the electronic timpani is derived from the requirements of the user,as presented in the description of the project brief.

19

Chapter 4 Specification 20

4.1 General attributes

• The mass of the electronic timpani system should be such that it can be easilycarried by one person.

• For the purpose of portability, the size of the entire electronic timpani systemshould fit within the luggage compartment of a typical saloon car.

• The entire system should be affordable to educational establishments and privatetutors. Additionally, it should cost significantly less than acoustic timpani.

• The system should be rugged enough to survive the handling it is likely to receivewith acceptable levels of degradation.

• If non-standard timpani mallets are required, they should be of similar mass anddimensions to typical classical timpani mallets.

4.2 Playing area

• The electronic timpani must contain a playing area which is struck with mallets.

• The playing area must be circular, or a section of a circle, and the surface mustbe flat.

• The size of the playing area must be comparable to that of a classical timpani:between 16 and 32 inches in diameter.

• The playing area must be at a similar height to the drumhead of a classical timpani,or must be suitable for placement on a table or similar surface.

• The surface of the playing area must be strong enough to withstand a reasonablesuccession of strong strikes from all varieties of timpani mallet.

• The surface must be such that the reaction force applied to the timpani mallet isas similar as possible to that from a classical timpani drum head.

• Noise produced by a strike on the playing surface must not interfere with soundgenerated by the system.

• Damping must be performed on the same playing area as the strikes.

4.3 Operation

• The system should be responsive to changes in the radial position of strikes.

• The system should be responsive to changes in the strength of strikes.

Chapter 4 Specification 21

• The system should be responsive to the occurrence of damping (placing of player’shand or finger on the playing surface).

• The system must incorporate a tuning device similar to the pedal of a classicaltimpani and should be responsive to the position of this device.

4.4 Sound

• The electronic timpani should create a sound similar to that of a classical timpanigiven the same input conditions.

• The electronic timpani should be able to reproduce playing techniques such as rollsand glissando (as described in section 1.3.3).

• The level of noise and distortion present in the sound output of the electronictimpani should not be noticeable under normal operation.

• The output of the electronic timpani should be compatible with commonly usedaudio equipment.

• The frequency content of the sound output need not contain components higheror lower than the audible range of human hearing.

Chapter 5

Hardware

This section describes the design processes and development of the electronic timpanihardware. First the requirements of the hardware are defined, and a detailed assessmentof the available sensor technologies is presented. The development sections then describethe design processes for the other principal features of the hardware.

It is important to re-iterate that the hardware is not required to calculate the positionand strength of the mallet strikes, but instead to provide raw sensor information to thesoftware. (The algorithms used for the software calculation are described later in Section7.1.4.) This design feature aims to maximise the flexibility of the system, since changesto software can be implemented significantly faster than changes to hardware.

22

Chapter 5 Hardware 23

5.1 Sensors Selection

One of the first stages in the design process was to research the available sensor tech-nologies. This was an immediately tangible area that was certain to be an essential partof the electronic timpani. The choice of sensors used would dictate the requirements andstructure of the remaining hardware. To gain a larger range of ideas, the brief for theresearch simply stated that some method would be required to transform the player’smovement into a signal that could be interpreted by the software. Limiting the sensorrequirement to this simple brief allowed the broadest spectrum of technologies to beconsidered.

The initial brainstorming session yielded the following principle ideas (as well as variousother ideas):

• CameraThe output of a camera ‘watching’ the strikes can be processed to extract theposition of the mallet and/or playing surface.

• Drum Pads

• MicrophoneSignals from a microphone placed under a simulated timpani skin can be processedto extract information about the mallet strikes.

• Piezo TransducersPiezo sensors produce a voltage across the output terminals when subjected to amechanical stress.

• Strain GaugesThe electrical resistance of the gauge varies with strain.

• AccelerometersAn electrical output signal is generated, proportional to the acceleration to whichthe device is subjected. This was not further investigated as it would rely on othertechnologies to provide positional and damping information, which would renderit superfluous.

• Resistive FoamForce can be detected by changes in the resistance of the foam as it is compressed.

• Hall Effect SensorsThe movement of a semiconductor through a magnetic field produces a voltage.


As there was no one apparent optimum solution, many of these ideas warranted furtherinvestigation. The following sections present each method, and compare the advantagesand disadvantages.

5.1.1 Camera

Cameras are being used in many measuring environments where it is important thatthe measurand is undisturbed. Their traditional Achilles heel has been the processingpower requirements, however recent advances in the personal computing market havegone a long way to mitigating this. Other problems, such as cost and ruggedness, havebeen substantially surmounted by the emergence of the webcam - a small and very cheapdevice. It is therefore sensible to assess them for inclusion in the project.

The camera could be used in two ways:

Upward Looking

This method relies on placing an upward looking camera underneath the skin of a mocktimpani. The camera would measure the disturbance of a graticule (grid of lines, “blobs”and fiducial marks) that would be printed on the underside of the timpani skin. Thisapproach has been successfully used on a much smaller scale in robotic finger tips (30).

Side Mounted

Alternatively a side mounted camera could track the movement of the mallet. Thiscould potentially give much better information about strike speed, but would sacrificeinformation about strike position. For this approach to work it is essential to distinguishthe mallet from other background data. This could be done in several ways:

• Frame DifferencingVideo hardware often allows the difference between two frames to be accessed,rather than the frames themselves. This would make extracting the moving com-ponents of a scene reasonably trivial. Once this has been done the processor mustthen distinguish between the mallet head, the mallet stick, the arms of the playerand any other background movement. This should be possible in a controlled en-vironment but may be difficult in a practical situation where there may be a lotof background movement.

• Colour KeyingThe processor could be “keyed” to look for a certain colour. If a colour were foundthat rarely occurred in the background then identification of the mallets would


be easier. The system would have to be able to compensate for different lightingconditions, and may therefore not be practicable.

• Other Spectral BandsThe amount of background information varies considerably in different sections ofthe electromagnetic spectrum. If the mallet heads could be heated to 50C, it maybe possible to use a thermal camera to identify them. Unfortunately this wouldrequire a specialist camera and is therefore likely to be prohibitively expensive.

All of the above techniques rely on good calibration; if the system is to be able to detecta strike it must first know where the timpani skin is. This may be achievable by placingthe camera in the same plane as the skin (which would waste half the image), but if thecamera were placed elsewhere then it would be difficult to handle the issues presentedby depth compensation.

Advantages

• There is little or no effect on the behaviour of the timpani skin itself, thus allowingthe playing experience to be as realistic as possible.

• This method would give very detailed information about the playing surface. Ifthe data were in a processable format, this could lead to an extremely hi-fidelitysystem.

• One potential advantage of a camera based system is to avoid latency. The cameracould literally “see it coming”. This may allow the system to compensate for slightprocessing delays by pre-empting the input.

Disadvantages

• The cost of the camera system is likely to be high. This may be prohibitivedepending on what grade of system is required.

• The camera system is likely to be moderately fragile.

• This type of system is likely to produce far too much data, creating a processingload that does not contribute to the final output.

• Technologically this is a difficult option and although it may produce good resultsit may not be possible to achieve them in the given time frame.


5.1.2 Electronic Drum Pads

After their first appearance in the 1970s, drum pads have evolved to give an impressivesound output and good tactile response. Appendix A contains details of a currentlyavailable position sensing drum pad. There are two main types of pad, those that use arigid rubberised surface and those that use a skin for a more realistic playing experience.

The drum pad will need little adaptation for use as an electronic timpani. The design issuch that the units can be mounted on commercially available stands, played with un-modified timpani sticks and interfaced to the rest of the system with the manufacturers’standard connectors.

Advantages

• The electronic drum pad is already robustly designed and attractively styled, andthe outputs are engineered to interface with a drum synthesizer module. They canbe readily adapted for the purpose of the electronic timpani.

• The two primary sensing priorities are fulfilled in a single unit: force and positionsensing.

Disadvantages

• The maximum diameter of position sensing pads is limited to twelve inches (300mm).The specifications of the electronic timpani require that a diameter of at least six-teen inches are required.

• Drum pads are considerably more expensive than raw sensors. However any sensorsbuilt from scratch will entail the extra costs of a custom enclosure, mounting, andsignal amplification hardware.

• Current position sensing drum pads do not provide the radial accuracy requiredfor this application.

5.1.3 Resistive Foam

Resistive foam has been used in the robotics industry in an attempt to construct tactilesensors (7). The technique uses a resistive elastomer, normally carbon doped rubber.This rubber is placed on a substrate that contains an array of dots and rings. The foamprovides the conducting path between each dot and ring. During use, each ring-dot pairis energised in turn, and the resistance between them is measured. The resistance of thefoam varies when it is compressed, which means a “image” of the tactile surface can bereproduced.


Advantages

• The system is reasonably rugged and should be able to survive general handling.

• The system is light.

• The system should be comparatively cheap to make and test.

Disadvantages

• The elastomer has a non-linear time constant. It is also hysteric: the time constantfor the application of force is different to that of force removal. This may meanthat this system does not give useful dynamic information, which is essential forthis application.

• Force-resistance characteristics of these sensors are highly non-linear, so the infor-mation will require considerable post-processing.

• The sensor will wear out relatively rapidly, particularly with the cyclic loading.The skin is likely to be struck non-uniformly, so high-use areas will degrade pref-erentially.

5.1.4 Hall Effect Sensors

This sensor is based on the physical principle of the Hall effect. A voltage, known asthe Hall voltage, is generated transversely to the current flow direction in an electricconductor if a magnetic field is applied perpendicularly. The Hall effect sensors are buildfrom semiconductor platelets as the effect is most pronounced in this material.

If a grid of small magnets were placed on the underside of a flexible membrane, an array ofhall sensors could be used to detect membrane deformation, and hence strike information.If the weight of the magnet proved too high and interfered with the movement of themembrane, they could be replaced by small electromagnets.

Advantages

• Inexpensive

• Widely used in the industry

• Very durable (30 billion operations)

• Fast (over 100 kHz is common) - low latency

• Small and light, so the design would be portable


• The “feel” of a hit on the drum would be very realistic as a real timpani skin couldbe used

Disadvantages

• If magnets significantly added to the mass of the membrane, its dynamic charac-teristics would be altered and may not respond fast enough

• As the Hall voltage is only a few mV, the system may not be sensitive enough todetect damping

5.1.5 Microphone

It could be possible to extract all the information required by listening to a drum skinwith a microphone. The position, velocity and damping will generate a unique signalwhich could be processed into separate components. Microphones are often used to pickup musical instruments, however they are not usually used to pick up precisely how andinstrument is played.

Using Microphones

If the microphone is placed too close to the source there could be the possibility ofclipping or distortion. The frequency response of microphones is usually fairly good,however there is usually a tail in the response at higher frequencies. Microphones aretuned to work in either a diffuse or free field. A flat frequency response is available butat a reduction in sensitivity and increase in cost.

The microphone will be very sensitive to ambient noise, which could be a significantproblem, for example in a teaching environment such as a classroom. The mounting ofthe microphones may be difficult and complex processing would be required.

Advantages

• Electret microphones are cheap (as little as 50p), rugged and reasonably stable

• They are available in very small packages

• Microphone behaviour is well documented

• All the information of hit profile; location and damping are included and could becontained in a single signal

• The microphone would also pick up any nuances of the playing that could bemissed by other types of sensor


Disadvantages

• The microphone will be very sensitive to background noise

• The microphone will require a high level of processing to determine some of theparameters, such as location of the hit

• Without experimentation it is impossible to tell how well a microphone would beable to pick up damping

5.1.6 Piezoelectric Transducers

The word “piezo” is derived from the Greek word for pressure. Piezoelectric transducerscan be used both as sensors and actuators. Acoustic electronic drum heads generally usepiezoelectric transducers because they are effective at detecting deformation velocity.

Piezo sensors can be used to develop a customised “drum pad” that suits the require-ments of the timpani, in terms of size, surface and responsivity. The construction of thepad would have to shield the sensors from excessive shock loading (which could damagethem) without muffling them.

There are several sensors configuration that could be used:

• Sensor MatrixA matrix of piezos could be placed under a thin rubber sheet. Location could thenbe determined by comparing their relative responses.

• Coaxial CablePiezoelectric coaxial cable is available which could be used as an alternative to amatrix. It may be easier to range into concentric rings. This would give accuratedistance from centre, but no angle information.

• Rigid PlateA rigid plate could be mounted upon piezos. This system would require moreprocessing to extract location information.

Advantages

• Inexpensive

• Piezos are small and light, allowing the final pad to be portable

• Fast response time due to low mass

• Currently used in similar applications


Disadvantages

• There is the possibility that if the piezos were inadequately protected, they couldbreak. The ceramic piezoelectric material is brittle and this must be taken intoconsideration when using this technology.

• This method alone would not easily allow the electronic timpani to detect damping.While piezos are very good at detecting short-term impulses, their detection of thesustained pressure on the pad (a hand damping the drum skin) would be poor.

5.1.7 Strain Gauge

Strain gauges operate on the principle of detecting changes in resistance of a materialas it is subjected to deformation. Generally the object under load is not a convenientlyresistive material, so the measurements are achieved by bonding a (usually small) latticeof wire, or foil, to the object under load. They can be used in a wide range of applications,from touch-sensitive notebook pads to weighbridges.

Position sensing can be achieved by placing multiple strain gauges around the perimeterof the playing area and analysing the distribution of the force between the sensors. Theplaying surface will be rigid to allow the force of the hit to be transmitted instantly, andundistorted, to the perimeter. Two force sensors would only resolve the hit location toone dimension, but three would allow the resolution of two dimensions. The use of foursensors would simplify processing requirements but will introduce problems if any onesensor is marginally out of vertical alignment.

A force sensor would consist of a strain gauge bonded to a solid material. Selectionof a suitable material, and a suitable shape, may prove unnecessary - force sensors arealready available in the form of load cells. These are purpose-built housings with internalstrain gauges already bonded in position, allowing the user to simply apply a force onthe load cell.

Load cells generally incorporate the first stage of the necessary signal processing elec-tronics: the use of a Wheatstone bridge to negate the effects of temperature and providea balanced output.

Recently patented load cell technology from C-Sensor uses polymer strain gauges and in-corporates all processing circuitry in one commercially available, extremely cost-effectivesolution. The units interface directly to the RS232 COM ports of a PC.

The polymer strain gauges operate on the principle of variations in capacitance, notresistance. DC output signals are achieved by integrating the polymer voltage withrespect to time, whereas with the resistive principle no such processing is required.


Advantages

• Strain gauges and load cells can easily be configured to provide position sensingand force/velocity measurement. For purposes of damping, they are especiallysuitable as the output is not capacitive (as in the case of microphones or piezosensors) and so will sense a ‘DC force’ such as a hand placed on the playing area.

• Load cells are a neater solution that raw strain gauges, as the calibration andassembly have been performed by the manufacturer. Polymer load cells are con-venient, as the amplification and communication electronics are integrated.

Disadvantages

• Raw strain gauges will require careful assembly and calibration, and the signalconditioning circuitry will need to be designed.

• Traditional load cells suffer the disadvantage of cost: the very cheapest availableare about £50; in more convenient housings they will cost £250 each. (Minimumof three required per timpani.)

• The patented polymer load cells may not be accurate enough - more research willhave to be conducted into the forces involved in heavy hits and light damping.

• They may also require calibration when turned on; this may be achievable auto-matically.

• The polymer load cells do not inherently sense DC force. The processing has beendeveloped by the manufacturer and so should prove reliable.

5.1.8 Conclusion

Several sensors were ruled out because they had significant disadvantages, these were:

• Camera: Too complex to build and the required processing power would not bejustified

• Foam: Unlikely to have the required dynamic response

• Hall Effect: Not sensitive enough

• Drum Pads: Not available in the required size and do not manage damping orposition well enough

Following this research, the team had sufficient information to decide on the technologyto use. All the techniques have their advantages and disadvantages, but the two most


suitable appear to be the piezoelectric transducers (piezos) and the strain gauges. Piezosare cheap, rugged and readily available, but do not respond to DC signals. Strain gaugeshave the advantage of providing better low frequency/DC information, but at a highercost.

Strikes and damping create signals with significantly different frequency content. Theduration of a mallet strike is of the order of milliseconds, and therefore high-frequency,while the pressing of a hand on the timpani may last for several seconds, and so consistsof much lower frequency components.

Given the suitability of piezos to the detection of high frequencies, and the suitability ofstrain gauges to the detection of low frequencies, the team concluded that a combinationof the two devices would provide the ideal solution. Piezos could be used to detect strikes,and strain gauges would detect damping. The detection and processing of strikes anddamping would thus be separated as early as possible, at the sensing stage.

Four further issues were considered:

• Following consultation with the project sponsor, the detection of strikes was to bea higher priority than the detection of damping.

• Compared to piezos, strain gauges would either require more development time toimplement into a hardware solution, or would cost significantly more if a ready-made implementation were to be purchased.

• Obtaining a stable hardware platform was essential in order to allow the softwaredevelopment to be started.

• At this early stage in the project it was important to conduct some experimentationand gain some practical insight into the operation of the sensors. Piezoelectrictransducers, costing less than £1 each, were an ideal starting point.

It was decided that some piezoelectric transducers should be purchased and assessed.Strain gauges would be added at a later date, once the hit detection was operational.On experimentation with some layers of rubber to protect the transducer, observing thevoltage output of the transducer with an oscilloscope, it was decided that the piezoelec-tric transducers were suitable as sensors for the electronic timpani. The development ofthe sensor assembly is described in Section 5.2.2.


5.2 Sensor Development

5.2.1 Hardware Structure

An overall structure was then chosen based on the hardware requirements and the se-lection of sensor technology:

• A flat ‘drum plate’ (the playing surface) should be supported on a sensor system,allowing all the force of the mallet strikes to be transmitted to the sensors.

• The output from the sensors would require some stages of analogue processing,followed by a conversion to digital values.

• The digital information would require ordering and formatting, before being trans-mitted to the PC.

• All the electronics would ideally be fitted onto one circuit board.

5.2.2 Sensor Assembly

Initial tests with piezoelectric transducers had been performed with the transducerplaced between layers of rubber to provide protection for the brittle ceramic layer inthe transducer. When struck hard with a timpani mallet, output pulses of about 5Vwere evident on an oscilloscope. When the plate was placed on top of the transducerand rubber, this output was reduced significantly to only 0.5V, as the rigid plate ontop of the transducer merely compressed it and did not flex it. Therefore some systemwas required both to protect the transducer and also to ensure that the impact of astrike would cause it to flex. Figures 5.1 and 5.2 illustrate the sensor assembly that wasdevised to meet these requirements. With this assembly, output voltages of up to 50Vare typically produced for a hard strike. The hard rubber base provides a relatively stiffsurface, against which the force of the strike can act from above. The layer of foamrubber damps the mechanical oscillation of the plate.

5.2.3 Configuration

The number of sensors used, and their configuration underneath the drum plate, affectother areas such as the data to be transmitted and the nature of the analogue processing.

The following considerations helped determine the configuration:

• Exactly three sensors would be required in order to correctly resolve strike position.Firstly this is a minimum governed by the requirement to obtain resolution in two


Hard rubber base

Foam rubber base

Piezoelectric transducer

Rigid base plate

Hard rubber surround

Foam rubber surround

Rigid drum plate

Figure 5.1: Sensor assembly between drum plate and base plate

Impact of mallet strike

Figure 5.2: Support layers deform piezoelectric transducer when struck

dimensions: one sensor measures a single magnitude, two sensors provide resolutionin one dimension, and three sensors provide resolution in two dimensions. Secondly,three contact points will sit firmly on any surface, whereas four may not. More thanthree sensors would provide redundant information, which would require carefulhandling.

• Alternatively an array of sensors under the entire pad - possibly hundreds - wouldindicate the location of a hit with one output being considerably higher than theothers. The disadvantage of this approach is the volume of information to betransmitted and processed.

• Placement of multiple sensors should be at regular intervals for symmetry andease of calculation, and around the edge of the pad so that mallet strikes wouldbe made between the sensors.

As a result of these design considerations, the three sensor assemblies would be placed onthe underside of the plate at separations of 120 as shown in Figure 5.3. These assemblieswould consist of a combination of strike detection sensors and damping detection sensorsif necessary.


Figure 5.3: Configuration of the sensor assemblies on the underside of the drum plate

5.2.4 Electrical Characteristics

The electrical characteristics of the sensors are an important consideration in predictingtheir behaviour, and creating the design of the electronic circuit for handling the outputsignals.

As a sounder, converting electrical energy into acoustic (or mechanical) energy, a piezo-electric transducer is commonly regarded as being primarily capacitive (8) (9). A typicalsounder consists of two thin conductive plates, separated by a thin layer of insulatingpiezoelectric material, giving it capacitive characteristics. This capacitance is also ob-served when the device acts as a sensor, and the output signal is therefore differentiated.

It is important to limit the current drawn from the piezoelectric transducer if the seriesoutput resistance is high (10-100kΩ), as it will lose a large proportion of the outputvoltage when current is drawn. Output resistance of the transducer is determined bycomparing loaded and unloaded voltage outputs. The difference between these voltageoutputs, combined with the value of the loading resistance, gives a value of approximately30kΩ. Any resistive loading of the transducers of below 30kΩ will therefore more thanhalve the output voltage, and so the signal must be amplified.

5.2.4.1 Frequency Response

A piezoelectric sounder typically exhibits an extremely high peak in the frequency re-sponse spectrum (typically at around 4kHz), due to the lack of mechanical and electricaldamping. The useful bandwidth is extremely narrow, and the low sensitivity across mostof the frequency spectrum renders the sensor unusable.

One established technique to improve the response of the piezoelectric transducer is toincrease the bandwidth by ‘detuning’ it. To achieve this, a relatively large inductanceand load resistor are connected in parallel with its output (10). The sensitivity in thepass band is reduced, but the overall response is vastly improved. The electronic timpanisensors use the mechanical inertia of the plate to achieve the same effect as the electricalinductance.


5.2.5 Use of Piezoelectric Transducers for Damping

Research and initial testing of the piezoelectric transducers confirmed that they are notsuitable for picking up DC signals, and so could not be used for damping. The outputis effectively proportional to the velocity of the drum plate, and not its displacement.A potential solution, to allow them to be used for damping, would be to integrate theoutput and thereby derive a value for displacement. Although this solution is initiallyappealing, drift errors will occur due to the integration of noise.

Damping information can be extracted from the piezoelectric sensors because a distinc-tive profile is generated. This is discussed in Section 7.2.11. Using this method, piezo-electric transducers will suffice for the purposes of the prototype without the additionof strain gauges (Section 5.1.8). Strain gauges may still present an optimal solution.

5.3 Drum Plate

As the principal interface between the player and the electronic timpani, the drum plateis required to accurately transmit information to the sensors when hit by the player.

Key parameters of the plate that had to be qualitatively defined were mass and stiffness.Mass should ideally be low, as the entire plate must move in order to transmit the impactof the mallet through to the sensors, and a high mass would decrease the movementfor a given impact energy. Stiffness should be high in order to minimise the bendingexperienced by the plate when hit, again in order to transmit the impact.

Recent advances in materials production have allowed honeycomb-structured panels tobecome more affordable and commonplace. They achieve an enormous overall strengthwhile maintaining a low density. As such they are ideal for the purpose of the drumplate. A sample of aluminium sandwich honeycomb cored panel was available free ofcharge (from a previous GDP) and presented an opportunity to try out the material.After being cut to a circular shape by the ECS mechanical workshop, the plate wasabout 340mm in diameter. This was smaller than the electronic timpani had originallybeen envisaged, but would be sufficient as a prototype.

5.4 Signal Conditioning

The following stages are needed to pass the values from the sensors through to the PC:

1. Amplitude adjustment

2. Buffering


3. Level shifting

4. Analogue-to-digital conversion

5. PIC microprocessor

6. RS232 communication to PC

5.4.1 Sensor Output Amplitude Adjustment

The first requirement of the analogue processing circuitry is that the output of thepiezoelectric transducers should be individually adjustable. This would account formanufacturing tolerances and ensure that the outputs are the same for a given strengthof hit. The scope for this adjustment is provided by the variable attenuation of thesignals with a 1MΩ potentiometer.

A balance must be achieved between resolution and headroom. If the sensor signal levelafter attenuation is too high, it will exceed the maximum voltage detectable by the bufferand analogue-to-digital converter (ADC), and cause clipping to occur, with undesirableeffects. If the attenuation is too low, the full span of the resolution of the ADC willnot be used, and resolution is lost. The calibration was performed with a professionaltimpanist, the project sponsor, playing what was considered to be the hardest reasonablehit.

5.4.2 Op-amp Buffer

The signals must be buffered in order to meet the input requirements of the analogue-to-digital converter (ADC). The ADC specification sheet (11, pp16) recommends thatthe output impedance of the analogue source should be less than 5kΩ to prevent noisepickup. However as discussed, the output from the piezoelectric transducer is adjustedthrough a 1MΩ potentiometer, which in this application will have an output impedanceof up to 250kΩ. To overcome this incompatibility, the output from the potentiometercan be amplified using the circuit shown in Figure 5.4. An operational amplifier (‘op-amp’) connected to present a high impedance to the input source while also having alow impedance output and unity gain.

Input Output

Figure 5.4: Operational amplifier connected to function as a voltage follower, or buffer


The buffer is supplied from both positive and negative rails, and so is capable of bufferingboth positive and negative signals from the sensors.

5.4.3 Signal Level Shift

Experimentation with the piezoelectric transducers and the analogue signal processingcircuitry indicated that the expected output from the potentiometer, and therefore fromthe buffer, is within -2.5V and +5V. Negative voltages are produced during the shortperiod of oscillation after the initial pulse of a strike. The input to the ADC must notfall below 0V, and must not exceed +5V. The signal levels must therefore be shifted,and this is achieved using a voltage divider to scale the voltage relative to +5V (fig.5.5). This shift creates an output of 80 from the ADC for a zero voltage output fromthe piezos. Subsequent software must take this into account.

Output from sensor

potentiometers

Input to ADCs

-2.5V

0V

+5V

-2.5V

0V

+5V

+1.56V

Figure 5.5: Level shift required to meet input voltage range of ADC

5.4.4 Pedal

The pedal input should transform a physical displacement into a quantity measurableby the PC. This is achieved using a commercially available electronic keyboard pedalas an analogue signal. The pedal simply contains a potentiometer, which is connectedbetween the positive and negative supply rails, giving an output voltage proportional toits angular position.

The only electrical requirement of the pedal potentiometer is that its output impedanceshould be low enough to allow the holding capacitor of the PIC ADC sufficient time tocharge. The maximum output impedance, as recommended by the PIC datasheet (12),is 10kΩ. The output impedance of the potentiometer can be shown to be a maximumof 0.25R where R is the total potentiometer resistance, so in this case R is limited to amaximum of 40kΩ.


5.5 Digital Development

5.5.1 Choice of Communication Systems

The system used for communication to the PC affects the digital components of thehardware.

5.5.1.1 Initial Data Rate Calculation

The deciding factor for a communication system is likely to be the data transfer rate, soan approximate value should first be established. There are three sensor values to trans-mit, and a digital resolution of 10 bits. Previous timpani modelling work (1) suggeststhat the duration of a mallet strike is of the order of 10ms. To capture this informationaccurately, a sampling period of 1ms would suffice. Based on these approximations, aminimum data rate of 30kbps would be required.

5.5.1.2 USB

The USB interface is rapidly becoming the standard for PC peripherals. Printers, scan-ners, modems, digital cameras and MP3 players are all making use of this flexible andcompact serial protocol. High data transfer rates are achievable: 12Mbps and 1.5Mbpsare the two common speeds and USB2 promises a 480Mbps rate. Online support isavailable, but the protocol is complex and development time may be high (13) (14).

5.5.1.3 Parallel port

Parallel port communication is the traditional standard for printers, with data rates ofup to 150kbps. The use of the parallel port would obviate the need to convert the datato serial format. However the ready availability of purpose-built serial chips allows thisconversion to be performed conveniently.

5.5.1.4 Bluetooth

Bluetooth is a wireless protocol and has only recently arrived on the market. As such,support is limited and hardware is expensive, but data transfer rates can be as high as10MBps for the latest versions.


5.5.1.5 RS-232

The RS-232 serial protocol is widely acknowledged as the most user-friendly interface.As such, it is frequently used for basic electronics projects, and the support availableonline is extensive (15). Data rates of over 100kbps are possible, and debugging softwarecan be downloaded freely.

5.5.1.6 Chosen System

All of these communication systems exceed the requirements for the data transfer rate.RS-232 was chosen as the preferred option, due to the comprehensive support, low costhardware, and above all the availability of peripheral controllers with built-in RS-232support.

5.5.2 Selection of Processing Components

The hardware needs some components that can be configured to control the communi-cation to the PC. These must provide:

• Rapid re-programmability to facilitate development

• RS-232 serial communications to interface to the PC

• Multiple analogue inputs to take readings of sensor outputs

All of these features were available on a single PIC microcontroller, the PIC16F871 (12),which is commonly available. The analogue inputs are digitised with an internal 10-bitADC.

5.5.3 Use of External ADCs

The original intention was to use the PIC analogue inputs for all three piezoelectrictransducers. Once the PIC had been purchased and programmed, it became apparentthat it operated by multiplexing the analogue input channels into one ADC, as illustratedin figure 5.6.

The PIC would therefore sample the analogue channels sequentially, with a delay of atleast 40µs between successive samples (12), or 80µs between the first and last of the threeconversions. Approximating the pulse of a mallet strike as a linear rise over a period of2ms, this would lead to an error of 4% in the readings. This should be avoided, so thePIC internal ADC was deemed unsuitable.


PIC

ADC

Switch

(multiplexer)

Channel 3

Channel 2

Channel 1

Figure 5.6: PIC switches all analogue channels to a single ADC

Two solutions appeared viable. An analogue sample-and-hold device could be connectedbetween the sensors and the PIC, to hold all three sensor outputs constant (fig. 5.7).As a result, the delay between conversions in the PIC internal ADC would not affect thevalue of the sensor voltage reading. Alternatively three separate external ADCs couldbe added (fig. 5.8). These would provide digital information which could be read inon the PIC digital ports, and would be easily upgradeable if different ADCs were laterrequired. The delay between readings from the PIC digital ports is negligible. Thislatter solution was preferable due to the ready availability of ADCs. Due to the numberof pins available on each PIC digital port, however, the ADC resolution was limited to8 bits.

Analogue sample- and-hold

Ana

logu

e ch

anne

ls

Dig

ital

chan

nels

PIC

Sensor

Sensor

Sensor

Analogue signals



Analogue signals

Figure 5.7: Potential solution: External analogue sample-and-hold

ADC

ADC

ADC

Ana

logu

e ch

anne

ls

Dig

ital

chan

nels

PIC

Sensor

Sensor

Sensor

Analogue signals

Digital signals

Figure 5.8: Preferred solution: External analogue-to-digital converters

The ADC sampling rate must be faster than the rate at which the PIC will be reading it,to ensure that no readings are repeated. The delay between successive conversions of theADC is 100µs, as specified in the ADC datasheet, (11). This gives a sample frequencyof 10kHz. The PIC would be sampling at around 1kHz as calculated in Section 5.5.1.1,and so the ADC sample rate meets this requirement.


The PIC internal ADC would still be suitable for the tuning pedal, as timing is notcritical - the pedal output is a much slower signal than the output from the piezoelectrictransducers.

5.5.4 PIC Code Development

The development of the code written to program the PIC microcontroller evolved throughseveral stages. Initially the functionality was simple, in order to verify the operation ofthe analogue and serial circuitry. As development of the serial input processing codecontinued, and to facilitate debugging of the hardware, additional modes of operationwere included in the PIC code. Once the final mode of operation was decided upon,the code was trimmed back down to an efficient minimum and optimised to excluderedundant functions.

One of the intermediate stages of code involved a mode that only transmitted the sensorreadings when they exceeded a certain noise threshold. This allowed strikes on the drumplate to be captured on the PC instead of being lost in the stream of continuous data.Another example enabled the full ten bits of data from the PIC internal ADCs to beused, to increase resolution. As a maximum of 8 bits per data word were admissibleover the RS-232 serial link, this involved rearrangement of the bits before transmission.

5.5.5 Serial Communication Voltage Levels

Two different voltage levels are used for serial communication. Between microchips(TTL or CMOS), 0V represents the low signal level (digital 0), and +5V representsa high signal level (digital 1). For communication over longer distances, the RS-232voltage is higher in order to improve reliability, so +10V is typically the low signal leveland -10V is typically the high signal level. Figure 5.9 shows the voltage levels of thedata word ‘137’.

8 16 32 64 128 4 2 1

LSB MSB

1 0 0 0 1 0 0 1

3 4 5 6 7 2 1 0 Stop Start Logic '1'

Logic '0' +5V 0V

x = 1 + 8 + 128 = 137

3 4 5 6 7 2 1 0 Stop Start Logic '1'

Logic '0'

+3V to +25V

-3V to -25V

TTL/CMOS levels

RS232 levels

Figure 5.9: Voltage levels of serial communication for TTL/CMOS and RS-232

A conversion is required to interface the two standards. Many varieties of integratedcircuits are available to perform this, most of which will provide level shifting in bothdirections, and often with multiple channels. For this application a MAX232 devicesuited the requirements, providing two input channels and two output channels.


5.5.6 Format of PIC-PC RS-232 Communication

The PIC is required to transmit three 8-bit readings from the piezoelectric sensors viathe external ADCs and one 8-bit reading from the pedal input via the internal ADC. Asone byte of RS-232 data can contain a maximum of 8 bits of information, these readingswill each fit neatly into one byte. Each byte is made up to ten bits with the addition ofthe start bit and stop bit. The data must be sent sequentially, so a known start byte isrequired to ensure that communication is synchronised and correctly interpreted. Thisstart byte is given the value of 255, as sensor readings are rarely expected to reach thishigh. All sensor or pedal readings with a value of 255 are trimmed to 254, again to avoidmisinterpretation. To maximise the frequency at which sensor readings are taken, startbytes are alternated with pedal readings, so that for every two sets of sensor readingsthere is one start byte and one pedal reading.

Start Byte Sensor A Sensor B Sensor C Pedal Sensor A Sensor B Sensor C

5.6 Noise

Minimising noise is essential to successful circuit design. The prototype circuit boardfor the electronic timpani has been constructed using wire-wrap pins to facilitate devel-opment, and the noise level is consequently higher than it would be with a commercialequivalent.

Noise is evident on the data received by the PC: the two lowest significant bits onthe ADCs can be seen randomly oscillating between 0 and 1 when monitored with anoscilloscope.

Some design measures have been taken in an effort to reduce noise:

• The design of the circuit features dual power supply regulation to separate analogueand digital power rails. This prevents noise from digital devices affecting theprocessing of the analogue signals.

• Filtering capacitors have been added to the power supply connections of many ofthe ICs, wherever circuit board space allowed. These prevent both the input ofnoise into the IC power supply as well as the output. Clocking ICs are particularlysusceptible to the production of noise, due to the increase in current drawn oneach clock edge (16). An increase in current causes a voltage drop across the seriesresistance of the connection from the power supply, and this drop in supply voltagewill affect other ICs. These capacitors must be placed as close as possible to thepower pins of the IC in order to maximise their effectiveness.


• The wire-wrap pins of the IC sockets are typically 25mm long. This exacerbatesthe noise levels by acting as a tiny aerial, transmitting and receiving noise elec-tromagnetically. Trimming these pins down to a more suitable length of 5-10mm,without jeopardising the ability to make future wire-wrap connections, reducedthe noise by one quantisation level (out of 255). In fact the datasheet for theADC specifically recommends against the use of wire-wrap sockets (11), but forprototyping purposes, the flexibility of the wire-wrap connections are a priority,and the decrease in signal-to-noise ratio (SNR) must be tolerated.

There are many areas for further improvements to the circuit design to reduce noise.

• Signal routing: Analogue and digital signals must be well separated. Efforts havebeen made to route the signals with this constraint, but cross-talk is unavoidablewhen wire-wrap wires are used (17).

• High-precision components: The voltage reference for the ADC is currentlya voltage divider using standard resistor, and is thus far from ideal. A precisionzener diode or reference voltage generator would be far more suitable.

• Use of PCBs: Cross-talk would be further reduced if the circuit were to becommitted to a printed circuit board (PCB)

5.7 Development Summary

The requirements of the electronic hardware were significantly simpler than if a fullyembedded system had been used. This allowed the hardware to be rapidly defined andimplemented, so that the software (particularly the input processing) could be devel-oped. The issues arising during the hardware development had to be resolved quicklyto produce a working prototype. Consequently there are several areas for future devel-opment, notably the addition of strain gauges and potential improvements to resolutionand communications speed. These developments are detailed further in the projectrecommendations, Section 11.

Chapter 6

Software System Design and

Implementation

This section will outline the design processes that were followed during the selection andprogramming of the electronic timpani system software.

45

Chapter 6 Software System Design and Implementation 46

6.1 System Overview

The proposed system uses a single processing unit and will be used to generate thesound for all of the timpani in the system. Rather than designing a system capable ofsupporting multiple timpani, the prototype will only manage one, however it will bedesigned so that the extension to multiple timpani inputs is trivial. The software will beresponsible for scanning a serial port and extracting piezo and pedal position informationfrom this data stream. It will then perform hit detection and sound generation (hitdetection details will be covered in chapter 7). The objective here is to produce amodularised platform that can be used to test and develop sound generation techniquesfor this application. As part of this process, initial sound generation modules will bedesigned and implemented (chapter 8 covers sound generation details).

6.2 Platform Selection

6.2.1 Processing Hardware

This system will certainly require some form of signal processing. There are commerciallyavailable signal processing PCI boards that would manage this effectively. They providevery high performance calculations using hardware acceleration, including dedicateddigital sound processors (DSP’s) and field programmable gate arrays (FPGA’s). Nogroup members had enough experience to use these devices effectively given the projecttime frame. It was concluded that it was impractical to use them. An alternativeapproach would be to use a small, embedded style, PC. These are compact systems thatwould be ideally suitable for inclusion in a final product. They were not consideredsuitable as a development platform due to their limited processing capability and highcost. A standard desktop computer was used as it could serve a dual role, both asworkstation and a target platform.

6.2.2 Language

Several possible language options were available to the project. There were two con-flicting requirements: the language needed to be flexible and feature-rich to speed updevelopment, but also needed to be efficient to allow the final process to be implementedin real-time. Some languages, like Java, may have partially filled both these require-ments, but it was decided that a combination of Matlab based prototyping and a C basedimplementation would meet both these requirements fully. C++ was considered, as itwould have given distinct advantages in terms of modularity and structure. Experiencewith C++ varied dramatically within the group and it was decided the effort requiredoutweighed the potential benefits.


6.2.3 Sound Programming API (Application Programming Interface)

Rather than interacting directly with a piece of sound hardware, it is normal to use somesystem services to handle the communication. This would allow the same application towork independently from the actual device. There are several API available:

• Direct X (Microsoft): A proprietary programming interface that lets appli-cation software gain control over the system hardware, including graphics, gamecontrollers and sound cards (45).

• Direct DOS Sound (Microsoft): Many older Microsoft based programs ac-cessed the systems soundcard, via a system of hardware drivers and direct inter-rupt calls. These programs are still partially supported by more recent releases ofthe operating system.

• Open Source Sound (OSS/Free) (Linux): A very basic system that opensthe sound card as a character device, using ioctrl() calls to configure outputoptions (46).

• Advanced Linux Sound Architecture (Linux): A very capable alternativeto using OSS, this allows several applications to access the sound hardware simul-taneously (43).

• aRts (Linux): Analogue Real Time Synthesizer. This sits on top of either OSSor ALSA and acts as a sound server using the Common Sound Layer interface.This is usually available within the KDE desktop environment. There is also aGnome equivalent.

Most of these were specifically designed to allow multiple programs to access the soundhardware resources simultaneously. From an electronic timpani perspective, this is atbest a waste of effort, or at worst potentially embarrassing (a “you have mail” notice halfway through a concert would certainly be undesirable.) The system therefore needed anAPI that would give direct and exclusive access to the sound hardware with a minimumamount of services. Early research indicated that the OSS/Free system provided byLinux may suit these needs well.

6.2.4 Operating System

Although OSS looked like a promising sound API, it was still important to compare therelative merits of the available operating systems given the application’s requirements.There were two main contenders, namely Windows 2000/XP or Linux. A Windowsbased system was considered for reasons of familiarity.


As mentioned, this system may well be used in an educational environment. Musiciansare often familiar with unusual operating systems (Atari’s have a very strong history inMIDI development for example). However familiarity with operating system would notpresent a particular advantage if the system were eventually black boxed.

Linux appears to present a reasonable alternative, as it is highly configurable (i.e. theKernel can be recompiled to only include necessary components, and system servicescan be optimised). Several of the team members were initially unfamiliar with Linux,but there was enough experience within the group to make it a viable option.

Linux was selected as it seemed well suited to semi real-time applications and alsoprovided the OSS sound API which appeared suitable for this project. The software willbe developed with a minimum amount of operating system dependence to allow it to beeasily ported at a later date should the need arise.

6.3 Design Principles

This section briefly outlines some of the principles that lie behind the implementationof this system.

6.3.1 Modularisation

To the greatest extent possible, given the restrictions of time and programming language,the software should be separated into logically independent modules which have clearlydefined interfaces. Once established these interfaces should allow parallel, independent,development of software, and allow future maintenance and development of isolatedcomponents with a minimum amount of system modification. It is possible that differentparts of the program may run concurrently, using some time-slicing method (e.g. POSIXThreads), and this should be considered when defining the interfaces.

6.3.2 Data Flow

Modules should communicate via globally accessible data structures, with only one mod-ule allowed to write to each data structure. It will be considered good practice for amodule not to rely on the values/state of its outputs (i.e. only read upstream, onlyoutput downstream). This is particularly important if the interface operates across athread boundary.


6.3.3 Concurrency

It may be necessary to run several parts of the program concurrently. This is verycommon in programs that manage asynchronous hardware input and output. Any part ofthe program that handles hardware should not “busy-wait”. Busy-waiting is effectivelypolling the hardware resource until it is in a state to supply/receive data. Most operatingsystems provide services where a program can pause, freeing the processor until thehardware is ready. Use of such processes is essential if the system resources are to bemanaged correctly.

6.3.4 Naming Conventions

Where possible, functions and variables that serve similar purposes should be namedconsistently. This will increase system maintainability and facilitate development.

6.4 Layers

The system architecture was to be divided into three logically independent layers, namelyhardware interface, storage (effectively communications) and processing. To the greatestextent possible, these layers would be developed and tested independently (fig. 6.1).

Hardware

Storage

Processing

Figure 6.1: Program Layers

6.5 Interfaces

The layers communicate via a series of interfaces. These are defined in two ways: by thefunctions that each piece of software must provide, and then by the data structures that


they must use. The result of this process can be seen in timpani.h header file which isincluded in Appendix D.1.

6.6 POSIX Threads

6.6.1 What is a thread?

Traditionally a program may be considered to start at the beginning, run through aseries of consecutive commands and eventually exit. This model is satisfactory for manyprocesses, but not ideal for programs that must interact with external programs/hard-ware. Many operating systems allow the programmer to create a series of separateprograms (or processes) that run concurrently and communicate via a series of pipes orsockets (buffers that one process writes to and another reads from). This is not an idealsystem as the limitations caused by pipe/socket communication imposes constraints onthe programmer. Threads were developed as a solution to this problem. A threadedprogram is effectively a single process that has several points of execution. This hasthe advantage (and disadvantage) that all the threads share exactly the same set ofglobal variables. On a single processor system, the operating system is responsible forscheduling the threads so that they all get CPU time. How the CPU is shared betweenthreads depends on how the scheduler is configured.

6.6.2 Why are threads needed?

There are two processes over which the program does not have control, namely the rateat which the PIC sends data to the program and the rate at which the sound card plays.It must therefore adapt the rate at which it is running so that it does not send moredata than the soundcard can deal with (otherwise the write() function will just pausethe program until it is ready to deal with the excess data), and also so that it readsthe data coming from the PIC correctly. Managing this task is not trivial. The systemgenerates the waveform of an entire timpani sound at the moment of a strike. It doesthis as a single loop, but due to latency constraints, the playing of this waveform mustcommence before the generation has completed. (It takes several output write cycles tocomplete the generation.) The program must either handle all this scheduling itself, orrun parts of the program concurrently. It has been found that using POSIX threads isan ideal solution.

6.6.3 Limitations

Great care must be taken to ensure that threads do not damage each others’ variables.There are several methods of controlling access including Mutual Exclusive locks (mu-


tex’s) and semaphores. It has been unnecessary to use either of these approaches inthe program, because the data structures have been arranged so that only one threadwrites to them (the others just read them). It should be noted that some of the variablesare declared as “volatile”, which is very important because it stops the compiler’s opti-misations that would otherwise break the thread connectivity (it will shadow variableslocally, in a way that other threads would not see).

6.6.4 Exiting the Program

Handling the exit of the threaded program can be complex. The application is notresponsible for writing files, so to exit neatly all it must do is release the memory thatit has allocated, free the hardware and exit. A single global variable is therefore used.A signal handling function waits for a signal interrupt (SIGINT) to arrive and then setsthis global variable to be false. Once this is set to false all the threads’ main loops exitsimultaneously.

6.6.5 Future Alterations

There are two ways in which the scheduling could be improved.

• Main Loop Busy Wait: The main loop currently busy-waits which is not ideal.There may be some method of using a function to trigger it, but for now a solutionis not apparent.

• Scheduling: Currently the default scheduling is used, which means clicks may beheard on the speaker if any other program is run at the same time as the timpaniapplication. These are caused by the output loop not keeping up with the soundcard. There are several methods of increasing a thread’s priority, which shouldstop this happening, but a satisfactory arrangement has yet to be achieved (ineffect re-prioritising the thread locks the whole system).

6.7 Program Life Cycle

This section outlines the steps that compose the life cycle of the timpani software.

6.7.1 Initialisation

Each main section of the program has an initialisation function of the formvoid init module name(), where module name is the name of the module. This func-tion allocates all the memory required by the module during its entire life cycle, (i.e.


they should not do dynamic allocation in any other function). This is done so that themlockall() function can be used to ensure that all the program’s memory stays residentin RAM and is not archived to disk. (Loading memory pages to and from disk can causesignificant unexpected time delays, which may have an impact on a real-time program.)Once they have allocated memory, the initialisation functions then assign meaningfulstart values, which may involve scanning hardware, loading data from files or simplyzeroing arrays.

Initialisation functions are called in a specific order because, where possible, modulesrefer to variables in each other rather than using global definitions (e.g. the WaveTable

struct queries the SoundCardConfiguration struct to find out how many samples persecond are being outputted). The basic order is:

• Storage layers (input processing; strike table; continuous input table; wave table;channel buffer and sound output buffer)

• Modules (generate; channel filter and post filter)

After initialisation functions have terminated and the memory has been allocated, theinput and output threads are created. It is not necessary to spawn a thread for thegeneration module, as it uses the ‘main’ thread.

6.7.2 When a Strike Happens

Although the following section is numbered, it should be remembered that several ofthese actions may happen in parallel.

1. InputFrame GeneratedThe serial port class creates a continuous stream of InputFrames, which contain areading for each of the piezo sensors and the pedal. These InputFrames are passed

Serial Port

Capture

Input

Processing

(Hit & Damp

Dectection)

Channel

Filter

(Glissando

Damping)

Channel

Combination

(Clipping)

Strike

Wave

Generation

Post

Filter

Write

Output

Input

Thread

Output

Thread

Main

Thread

Blocked by select() Function Blocked by write() FunctionNot-Blocked

Figure 6.2: Program Break Down By Thread


to the input processing module via the save input frame(InputFrame *input)

function.

2. Hit DetectionThe input processing module monitors InputFrame stream, saving a damping andpedal value for every InputFrame using save continuous input(). If the in-put processing module detects a hit is saves it to the StrikeTable via the save strike()

function.

3. Wave GenerationThe generation module (mod generate) continuously scans the StrikeTable to see ifa new strike has been recorded. If it has, then it selects the parameters it requiresand then uses them to store the generated wave in the WaveTable. If all the wavesin the WaveTable are currently still being used (all notes are still ringing) then thegeneration sends a kill request to stop the oldest note before re-using it.

4. Wave Playback and ModificationThe channel filter is responsible for scanning the WaveTable and creating outputfragments for the waveforms that are currently playing. It has a lot of control overhow it reads the table and is currently implementing pitch shifting (for glissando)and amplitude enveloping (for damping), both of which processes are controlledby variables set in the ContinousInputTable (fig. 6.3). Playback can begin beforegeneration has completed, the process being managed via a series of global flags.

5. Channel CombinationOnce the channel filter has created a small fragment for each channel, these arecombined by the combine channels() function, which also ensures that the frag-ments clip properly (rather than overrun the variable value). There are severaltechniques that can be used to combine channels, whilst avoiding clipping. Thesimplest is to divide the amplitude of each channel, by the number of channelsbefore combining them. This is a very conservative approach, but would entirelyremove the possibility of the output clipping. It does this at the expense of dy-namic range. The sounds being playing are fairly specialised (i.e. sharp attackfollowed by rapid decay). This means that clipping is only likely to occur if twostrong strikes are played in quick succession. It may be necessary to perform somesort of amplitude reduction on the channels to avoid clipping, but this will haveto be calibrated manually once the multi-timpani system has been implemented.

6. Post FilteringThis single output fragment is passed to the post filter module (which currentlyunused). This could be used to implement some system-wide features, like tonecontrol.

7. Sound PlaybackOnce passed via the post filter module, the output fragment is written to the sound


card. The soundcard is configured to use minimal internal buffering in an attemptto minimise latency.

Channel

BufferWave Table

Output

Buffer

Generated Sample

Figure 6.3: Wave Table Playback

6.7.3 Termination

Once a termination request has been detected (i.e. a SIGINT has been received), theinput and output threads terminate. After they have terminated the main thread callsmunlockall() to free the memory lock, and calls terminate functions in the reverseorder to the initialise functions. Once all the memory is free, the hardware file locks arereleased and the program exists normally.

6.8 Software Future Developments

6.8.1 Extension to Multiple Timpani

Originally the post filter class was provided as a useful way of optimising the soundgeneration (by only performing some operations on the combined channels rather thanindividually), however it has been found to be unnecessary. This means that extensionto multiple timpani would involve minimal changes to the software structure. Changeswould include:

• Add new entry to strike table to give timpani number

• Create new continuous input table entry for each timpani


• Update sound generation module to reflect different size timpani (this is optional,it would be possible to have several different timpani of the same type withoutthis)

6.8.2 Complex Time-Varying Modelling

The current software architecture assumes that the output of the initial sound generationmodel can be expressed as a single sound wave, representing a timpani strike. These, asmentioned, are stored in the WaveTable structure and accessed by mod channel filter.This is a reasonably good assumption, but does not allow for a model that can respondto inputs that occur after the initial strike. It may be possible to generate a modelthat has two free parameters (for example damping and pedal position), that wouldthen have to be generated in the channel filter. In this case the WaveTable wouldhave to be replaced by some data structure that stored the parameters for that model,instead of a direct output waveform. This would require significant reconstruction of thesystem architecture as the WaveTable/ChannelFilter interface happens across a threadboundary. Where possible it is recommended that two separate models, one for strikerelated inputs and one for continuously variable inputs, are used in parallel.

Chapter 7

Input Processing

This chapter aims at describing how the serial port on a computer can be read and howthis was implemented in the system.

56

Chapter 7 Input Processing 57

7.1 Accessing Serial Port Data

As mentioned earlier, the electronic timpani is to provisionally use the RS232 serialinterface which allows easy communication between the hardware (PIC processor) andthe computer (for later versions, other standards such as USB or FireWire could beconsidered).

7.1.1 POSIX

POSIX stands for Portable Operating System Interface, and is an IEEE standard de-signed to facilitate portability by creating a single version of Unix. Most ‘UNIX-like’systems are therefore POSIX-compatible operating systems. Applications designed forsuch operating systems could theoretically also run under Microsoft Windows providingappropriate libraries are also included.

When using the POSIX standard, the serial port is accessed via a character device file,which is opened with some connection parameters defining interface protocol (such asparity, baudrate and handshaking). For Linux, the serial port character device file namesare /dev/ttyS0 and /dev/ttyS1. The specifications of these parameters in the context ofthis project will be detailed in section 9.1. Inputting and outputting to the serial portis then performed by reading and writing to this device file.(48)

7.1.2 Processing Requirements Issues

Receiving the data from the serial port can be achieved by polling it. This involvesthe computer continuously looking for data waiting at the serial port. This is a veryinefficient technique, as processing time is wasted when the CPU is polling and checkingthe port when no data is available. Other parts of the program require the CPU resourcesand this section should therefore only run when it is required. A system function call,select(), allows the input processing to pause until new data is available, freeing CPUresources.

7.1.3 Framework of Serial Port Software

As shown in the timpani header file (Appendix D.1), the serial port part of the softwarecontains three functions:

• init serial port() opens the port, stores old and sets new configuration param-eters.


• update serial port() is responsible for extracting an individual set of three piezosensor values within a frame from the incoming serial data, and then calling theappropriate save input frame() function to store them (section 5.5.6 containsdetails of the frame constitution).

• term serial port() closes the port and restores the old configuration parameters.

7.1.4 Interpretation of Serial Data

The update serial port() function manages the serial input stream. From this, itextracts sensor readings and stores them in an InputFrame. These InputFrames arestored using the save input frame() function.

Start Byte Sensor A Sensor B Sensor C Pedal Sensor A Sensor B Sensor C

A state variable is used to ensure that the input stream frames do not get unsynchronisedwhen individual bytes are lost in transmission.

When the program is waiting for a start byte, it is set into an ‘idle state’ where the statevariable is equal to 0. Every time a start byte is received, the state variable is set to1. At any other point, the state variable is incremented. When the last sensor value isread in (the state variable is 8), the program is set back into the idle state. This processis illustrated by fig. 7.1.

7.2 Input Processing Operation

7.2.1 Introduction

Before any sound generation can take place, the raw data must be converted into a seriesof strikes, damps and pedal movement. These are provided to the next processing stageas two structures: a ContinuousInputTable and a StrikeTable.

• The ContinuousInputTable contains pedal and damping strength information thatwould be updated continuously, as fast as necessary.

• The StrikeTable is only updated when a hit has been detected, and provides in-formation about the strike hit strength, distance from centre and pedal positionat time of strike.


"!$#

%&('*)+',.-0/

1(2*3+25476.89;:=< >@?ACBED*F(G(H+IKJLM?N.B

OPQSRMTVUXW+PT

YZ\[5]7^`_aab

c(d*e+df.g.hijk

lnmCo

Figure 7.1: State transition diagram of serial program

7.2.2 Framework of Input Processing Software

As can be seen in the timpani header file (Appendix D.1), the input processing part ofthe system involves four functions called from the main program:

• init input processing() is used to allocate memory to the various table buffersneeded for this processing stage.

• save input frame() fills the table buffers appropriately with values based on cal-culations from the raw sensor readings.

• update input processing() calls the appropriate internal functions to detect andinterpret hit and damping information.

• term input processing() frees the memory allocated for the buffers.

7.2.3 Buffering

Initially, the save input frame() function fills a rolling buffer, holding the values of thesensors obtained from the serial port. This is done because later calculations requirepast values.


7.2.4 Noise

Section 5.6 highlighted the noise present within the data at the input to the PC. Highand low frequencies of noise need to be considered separately. On a digital signal, run-length averaging can be used to remove high frequency noise (it is effectively a low-passfilter, fig. 7.2).

• A smoother curve without quantisation errors and with reduced glitches and high-frequency noise fluctuations.

• A delay introduced in the system of N − 1 samples, if averaging is performed overN samples. In the context of this project, as only very high frequencies need tobe removed, the running length N would typically be small enough for the delayto be negligible.

"!$#&%

'"(*),+ -.0/214365 7"8*92:<;>= ?"@*A2BDCFEGIH J KIL M NIO$P Q4R$S

TU0V,W

Figure 7.2: 4-Point Running Averaging Filter

Figure 7.3 displays the magnitude of the frequency response of a 5-point run-lengthaveraging filter. The X-axis represents normalised radian frequency ω (in radians),which is defined as:

ω =2πffs

(7.1)

wheref is frequencyfs is the sampling frequency

Only values from ω = −π to ω = π are shown, as the plot is periodic with period equalto 2π. The magnitude of the frequency response of a run-length averaging filter is zeroat specific frequencies. These are equal to: (36)

ω =2πkL

(7.2)

whereL is the length of the running averagerk is a constant = 1, 2, 3, ... L− 1

And so, for a 5-point running average, the first zero point is equal to 2π/5. This signifiesthat signals with a period of less than 5 sampling periods will be attenuated considerably.


−3 −2 −1 0 1 2 30

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1Magnitude of the Frequency Response for 5−Point Running Averager

Normalised Radian Frequency

Mag

nitu

de

Figure 7.3: Plot of the magnitude of the frequency response for a 5-point runningaveraging filter

In order to account for low frequencies a noise threshold value must be set. Any readingsthat are below this threshold are not certain to be accurate as they may be due to noise.No calculations should therefore be performed and no interpretations should be madeon such readings.

7.2.5 Zero Point

As the input data, generated from the ADC’s is limited from 0 to 254 (the number 255being used as a start byte in the frame), representing a voltage range from -2.5V to5V (section 5.4.3), it is necessary to discover exactly which quantisation level a sensorreading of 0V corresponds to. The precise quantisation level generated by the ADC’scannot be established from theoretical knowledge due to the fact that the resistors usedfor the 2.5V reference voltage may have tolerances associated with them. It is crucial tocalculate this value precisely, as all quantities need to be normalised according to thislevel.

7.2.6 Finding the Noise Threshold and the Zero Point

The best way to set both the zero point and the noise threshold accurately is to performa quick calibration during the initialisation of the input processing. The zero point isfound by calculating the average over 1000 readings. The noise threshold is set as beingtwice the maximum reading.


7.2.7 Hit Strength

Once a strike has been detected, it is necessary to evaluate the strike strength. Thedefinition of the interface to the sound generation software specifies the strength of hitmust be represented by a value from 0 to 1.

The following measures could typically be used to estimate this strength from the threepiezo readings:

• Maximum

• Median

• Minimum

• Mean

• RMS value

The maximum, median and minimum cannot be used as an estimation of the hit strengthbecause it is difficult to decouple position from strength information. Calculating thehit strength using these measures is further complicated by variation in sensor response.The RMS value could justifiably be used as a measure of the hit strength. However,as negative values invalidate this measure, the piezo outputs would have to be carefullylimited and normalised before they can be used in this fashion. The mean was selectedas a hit strength measure to simplify implementation. Few considerations need to betaken into account, and values can be used in any form. It is a sufficient approximationof a true measure of hit strength, providing it is scaled up.

It should be noted however that these measures all assume that the piezo outputs varylinearly with strength of hit. Although this may be a close approximation, experi-mentation on the prototype should be carried out to determine whether linearisationtransformations are necessary.

7.2.8 Peak Detection

A strike can be detected by locating the sharp peak, characteristic of its shape (fig. 7.4).

A mathematically rigorous approach to determining the occurrence of a maximum ina function is to differentiate and look for a zero first derivative and a negative secondderivative. An approximation to the first derivative of the function can be obtained fromthe difference in two values over a known time period:(

dy

dt

)n

wyn − yn−1

∆t(7.3)


0 5 10 15 20 25 30 35 40 450

50

100

150

200

250

Time (sample)

Str

engt

h (q

uant

isat

ion

leve

ls)

Strike Profile

Sensor ASensor BSensor CMean

Figure 7.4: Strike profile on drum plate

where y is the function, yn is the value of the function at time t = n and ∆t is theseparation between samples.

The second derivative is determined from the difference between two first derivativesover a known time period:

(d2y

dt2

)n

w

(dydt

)n−(dydt

)n−1

∆t(7.4)

Because the signal is digitised, the zero may not occur at a sampling point. However,its presence can be inferred from a zero-crossing, which is indicated by a sign change.The following equations indicate a zero-crossing:(

dy

dt

)n

> 0 and(dy

dt

)n−1

< 0 (7.5)

or(dy

dt

)n

< 0 and(dy

dt

)n−1

> 0 (7.6)


To distinguish maxima from minima, the second derivative is then required. Only atransition from positive to negative of the first derivative will indicate a negative secondderivative:

(d2y

dt2

)n

< 0 (7.7)

Equations 7.4 and 7.7 therefore imply that only equation 7.6 would indicate a maximum.So, from equations 7.6 and 7.3 the following conditions are requisite and sufficient forthe detection of a maximum:

yn−1 > yn (7.8)

and

yn−1 > yn−2 (7.9)

This demonstrates that if the middle out of three values is the highest, a maximumexists at point yn−1.

To avoid detection of noise-induced local maxima and minima, a larger set of readingscan be used. A peak is then redefined as the condition when the middle value is higherthan all the others in a larger buffer:

yn > yn−1 yn > yn−2 yn > yn−3 ... yn > yn−N

yn > yn+1 yn > yn+2 nt > yn+3 ... yn > yn+N

when a buffer length is 2N + 1.

It can also be observed that this derivation filter requires N future samples. As a causalsystem is required, and no forward-prediction is feasible, a delay of N samples needs tobe introduced.

Figure 7.5 illustrates the peak detection process on a strike example.

7.2.9 Determining Radial Distance

Two distinct quantities need to be obtained from the sensor readings: radial distanceand strength of hit. To extract radial distance, the readings must be normalised in sucha way that this information is separated from strength information. This is achieved bydividing all three values by the largest. The result will be that none of the normalisedvalues are greater than 1, and the values are all relative to one another.


1 2 3 4 5 6 7 8 9 10 110

50

100

150

200

250

300Sensor ASensor BSensor CMean

A peak is detected when the Middle Valueis higher than the others in the buffer.

Mean Middle Value

length = 7 BUFFER

Figure 7.5: Peak Detection Using a Buffer Length of 7

Assuming the perceived strengths of hit of sensors vary linearly with distance to thesensors, the following vector calculations can be performed:

The three sensor readings can be represented by three radial vectors pointing towardsthe sensors as shown in figure 7.6. Through simple trigonometry, it is then possible tofind the expressions for the x and y coordinates of the sum of the vectors. They aregiven by:

X = B sin 120 + C sin 240 = B

√3

2− C√

32

(7.10)

Y = A+B cos 120 + C cos 240 = A− B

2− C

2(7.11)

The radial distance is then obtained by calculating the norm of the vector:

Radial distance =√X2 + Y 2 (7.12)


"!$#&%(' )+*,!.-,/

0132,1&4+2,1 576$8&93: 2;: 8=<

Figure 7.6: Position finding using vectorial representation

Testing the position-finding equations above, in conjunction with the electronic timpanihardware, revealed that the strength perceived by the piezo sensors does not vary lin-early with distance. The assumption made previously is therefore inaccurate and it isnecessary to linearise equation 7.12 for the radial distance by applying some unknownfunction to it. This function would depend on the response of the sensors, the mechan-ical interaction of the sensors with the drum plate and layers of material in the sensorassembly.

The number of variables involved, and the complexity of the modelling problem, sug-gested that an empirical approach would be a more efficient use of time and wouldallow adjustment to account for unpredictable variations in the sensors’ characteristics.Raising equation 7.12 to a power is a convenient way of attempting this linearisation.A range of experiments were performed to determine the optimum power. Any furtherattempts at refining this transformation would not be productive due to inconsistencyin the piezo readings.

These equations only hold inside the triangle formed by the piezo sensors (fig. 7.7).Strikes that occur outside this triangle result in radial distances larger than 1. Onlyradial distances that lie between the centre and a sensor are accurate.

To compensate for this, angular position was required. The following two methods wereenvisaged to calculate this:

• Calculating the angular distance from the X - Y coordinates. (see figure 7.8).

θ =(

arctanY

X

)mod 120 (7.13)

• A measure of median−minimum could be used, where minimum is the lowest of


Sensor B

Sensor A

Sensor C

Position = 0

Valid range(Position < 1)

Invalid ranges (Position > 1)

Figure 7.7: Invalid position regions

Sensor B

Sensor A

Sensor C

Location of Hit

Figure 7.8: Angular representation of distance between sensors

the three sensor readings, and median is the middle one. When the pad is struckdirectly above a sensor, the other sensors should both be equal and close to zero,so median − minimum = 0. When the pad is hit exactly between two sensors,median = maximum, so median − minimum is at a peak. This measure thusvaries from 0 to 1 with angular distance from the nearest sensor.

The first method was rejected because the values of the X and Y coordinates could notbe relied upon. In effect, it would be using X and Y to correct X and Y .

As the original transformation is accurate on the lines between the centre and eachsensors, when median−minimum = 0, the new transformation should not differ from


the original in this case. This could be taken as a boundary condition. Thus, thetransformation formula was set to:

Transformed distance =Old distance

1 + k(median −minimum)p(7.14)

where k is the amount to scale the values down when the strike occurs on the edgebetween sensors, and p is a constant that makes this transformation consistent over thewhole edge of the pads

The values of p and k were initially estimated, and then fine-tuned through experimen-tation, so that they also accounted for sensitivity differences between sensors. k wasfound by setting median − minimum to 1 in order to eliminate the effect of p, andfinding which value would provide a position of 1 when the pad is hit on the edge. Oncek was set, p was then adjusted to obtain the desired consistency of values around theedge of the pad.

The various transformations used provide an acceptably consistent representation ofradial distance.

7.2.10 Ringing Effects and Bouncing of Pad

Vibrations caused by strikes on the drum plate propagate through the material and thusproduce ‘ringing’ effects in the piezo readings. In terms of strike detection, this resultsin the creation of misleading secondary peaks that should be ignored. Ringing effectsbecome insignificant after about 30 to 40 samples which is equivalent to about 12 ms(fig. 7.4). Considering the period of a typical timpani roll is much higher (about 50 ms),it is quite safe not to perform any processing and detection algorithms on 20 ms (or 60samples) after a hit has been detected.

A further detrimental effect occurs when the pad is not properly secured and bouncesoff the surface after a hard hit. The piezo transducers perceive as a second strike. Thetime between the actual hit and the perceived hit due to the bounce is likely to be higherthan the period of a fast roll, which suggests it may not be ignored. For this reason, itis essential that the pad be properly secured.

7.2.11 Damping Detection

The profile of a damp is very different to that of a hit (fig. 7.9). When the padis depressed, the piezo transducers deform generating a slowly rising signal. Once thepiezos stop being deformed, the signal peaks, and starts to fall slowly, eventually reachingzero. Removing the hand from the pad allows the transducers to relax back into theiroriginal state, which generates a negative curve.


0 500 1000 1500 2000 25000

20

40

60

80

100

120

140

Time (samples)

Str

engt

h (q

uant

isat

ion

leve

ls)

Damp Profile on Pad

Sensor ASensor BSensor CMean

Onset of Damp

Offset of damp

Figure 7.9: Sensor profile of damping

This onset and offset therefore need to be found in order to detect damping. The twopulses that are generated by the piezoelectric sensors are associated with the slope (firstderivative) of the actual damping information that needs to be extracted. The mathe-matically rigorous method for extracting damping information is therefore integration.Although this could be performed by the cumulative summing of readings, the problemwith this technique have already been discussed (section 5.2.5).

A more conceptual approach may be preferable. As the damping is a much slower signalthan a hit, the two can be distinguished using a threshold on rise time. Looking at therise time towards a peak is not sufficient though, as local peaks occur quite frequentlyin the damping signal and would detected as small strikes.

To ensure this does not interfere with the damping distinction process, it would bebetter to measure the time for the whole pulse to occur. Experimental data revealedthat the signal associated with a strike on the pad lasted for about four to ten samples,depending on the hit strength. It would therefore be safe to assume that a signal thattakes more than twenty samples to reach rise, reach its peak and drop below the noisethreshold again, is caused by damping.


When this algorithm was implemented, a problem was soon discovered with this methodof detection: the onset of the damping is too slow and noisy (fig. 7.9). During the onsetof damping, signal noise causes chatter around the detection threshold, which producesa stream of small hits to be detected. This effect could be compensated for by usinghysteresis in the threshold setting. Another approach is to smooth the signal to removenoise by performing a running average (section 7.2.4).

Once the onset of the damping is detected, it is essential to find when the hand is removedfrom the pad. The problem with using a peak-detection based algorithm, such as theone previously described, is that strikes also create a series of negative peaks. Withoutadditional distinction algorithms, these would be interpreted as damping endings.

Rather than using negative peaks to detect the end of a damp, a counter records allthe time the signal spends below the negative noise threshold (which is defined aszero point − positive noise threshold). This counter is reset every time the signal risesabove the negative threshold. By comparing the time spent below the negative noisethreshold, a damp offset and a strike bounce can be distinguished. A threshold ofbetween 20 and 100 readings was found to be reasonable.

7.2.12 Trade-off

With the current analogue to digital conversion resolution of 8 bits for the piezos, thesolution lies ultimately in a trade-off between rejection of spurious hits when damping,and detection of light hits. In order to get damping working properly for the prototype,all hits weaker than a strength of 2 quantisation levels are rejected. Additionally, toremove problematic glitches in the signal, such as those caused by high frequency com-ponents of the noise, the peaks that have a rise time that is too small for them to becaused by strikes could be ignored.

7.2.13 Main Structure of Software

The code in the update input processing() function, has been divided into sub-functions to modularise the individual detection tasks (fig. 7.10):

• is damp(): Performs damping detection and returns true when a damping is inprogress. It also returns the current strength of damping.

• is end of damp(): Looks for an offset of a damp and returns true if one is found.

• is hit(): Performs hit detection and returns true when a strike has been detected.It also returns the strength of the hit.


• was hit(): When a strike is very light, the program first ensures it is not the startof a damp. This function returns true when it has established that a small recentpeak was a strike on the pad rather than a damp.

Storage Process Frame

is_damp()

End Dampis_end_of_damp()

was_hit()

SaveContinuous Table

SaveStrike Table

Find_Distance()

SmallStrength?

is_hit()

Smoothed Buf

ferMean

Damp Strength

Stored StengthStored Position

Store Strength and Position

Hit Strength

Hit Strength

Yes

No

Y

es

Y

es

Y

es

Serial PortData

Figure 7.10: Input Processing Program Structure and Operation

In order to make the program flexible, all the control parameters were defined at thestart of the file. Where possible, functions were written in a versatile manner using theseparameters to modify the behaviour.


7.2.14 Interfacing with the Sound Generation

As explained in chapter 6, strike and damping information need to be conveyed to thegeneration module. When a strike has been detected, the position finding function iscalled. The radial distance, the strength and pedal position during the strike are allstored in a struct and passed to the save strike() function, which stores them in theStrikeTable.

The channel filter module requires the level of damping continuously. The piezo sensorsonly provide a measure of velocity, which creates a positive peak during the onset ofa damp and a negative peak during the offset (fig. 7.9). In order to provide a contin-uous measure of the damping, the maximum value of the damping signal is held untilthe end of the damp. This creates a signal that is analogous to an integral of the in-put. Once this value is scaled and normalised between 0 and 1, it is then stored in astruct and passed to the save continuous input() function, which stores them in theContinuousInputTable.

7.3 Future work

7.3.1 Digital Filtering

It would be possible to implement an improved strike and damping detection methodusing digital filters. The frequency components in a signal associated with a strike aremuch higher than those in a damp(fig. 7.4 and fig. 7.9). A strike signal containsfrequencies of at least 200Hz, whereas if a damp is assumed to last between 0.5 and 10seconds, the frequencies are in the area of 0.1Hz to 2Hz.

It would therefore be sensible to extract the appropriate information through a combina-tion of low pass and high pass filters. Initially, a high-pass filter with a cut-off frequencyof about 20Hz would extract the strike information and remove all the low frequenciesinfluenced by damping. The peak detection, together with the strength and positioninterpretation, could then be performed on the resulting signal.

At the same time, a low-pass filter with a cut-off frequency of about 20Hz would removethe strike information and provide a clean profile of the damping. As was explainedearlier, the mathematical method of extracting the damping information would involveintegrating the signal, which could be approximated by calculating a running sum of thereadings. However, the difference between the onset and offset of damping, caused bythe non-linearity of the piezoelectric transducers, would generate a DC drift. In orderto resolve this, a further high pass filter of 0.1Hz would have to be applied to the signal,which would remove this drift, and tail-off the damping after 10 seconds if an offset ofa damp was not detected.


The main reason why this method would be more effective is that it resolves all theproblems associated with the distinction between strikes and damps. The simplest formof digital filter is a finite impulse response (FIR) filter (such as the run-length averagingfilter described in section 7.2.4), which depends solely on scaled current and old inputvalues. The problem associated with using such a filter is that it often necessitates largedelays and storage while not being very flexible. For example, this delay is noticeablylarge for a low-pass filter with a low cut-off frequency.

A more efficient way of implementing such filters would be to use infinite impulse re-sponse (IIR) filters that depend on current and old values of the input as well as oldvalues of the filter output. As the past values of the filter output are fed back to itsinputs, the IIR filter is potentially unstable. If designed correctly, they are stable andrequire fewer terms than an FIR filter.

A crude example of a low-pass or high-pass IIR filter is:

y[n] = x[n] + a.x[n− 1] + b.y[n− 1] (7.15)

wherex[n] is the input to the filter at time ny[n] is the output of the filter at time ny[n− 1] is the output of the filter at time n− 1a and b are constants.

If a and b are positive, the filter is low-pass, whereas if they are negative, the filteris high-pass. Modifying these constants would emphasize or de-emphasize the variousfrequencies. In order to ensure the filter is stable, b must be between -1 and 1. There aremany more examples of filters, which would have more complex equations. These includethe standard Bessel, Butterworth or Chebyshev filters, and custom designs. There aremany textbooks that cover filter design in far more depth (36) (41) (38).

7.3.2 Machine Learning

Machine learning could be used as an alternative to digital filtering. There are severaltechniques that would transform the sensor readings directly into hit and damping in-formation. Foremost of these is Support Vector Machines (SVM), which can be used forboth classification (strike detection) and regression (generalised model fitting).

The input processing subsystem has three inputs, namely the three sensor readings, andshould provide two outputs: radial distance and strength. In order to perform datacollection rigorously, a method is required for consistently striking the pad at specificlocations and with specific strengths. Such a device was constructed with a view toimplementing a SVM solution (fig. 7.11). Once the dataspace has been obtained, the


SVM would generate (offline) a model of the relationship between sensor readings andthe required outputs. This model could then be used to transform sensor readings inreal-time. Inclusion of other output variables, such as angular strike position, would notrequire significant alterations to the system and may prove useful in later applications(e.g. steel drum).

Problems may occur with dimensionality, if the readings need to be considered as streamsrather than individual time slices. This may make machine learning unsuitable. Thequality of the result will depend on how effectively the training data is collected andhow complex a model is required.

This technique will be explored further in section 8.4.

7.3.3 Improved Peak Detection

It can be observed that the peaks in the signal from the sensors do not occur syn-chronously (fig. 7.4). This is probably due to the dynamics of the drum plate. Thestrength and positional information may be imprecise and inconsistent, as they arebased on the mean of the sensor signals. It would therefore be better to perform peakdetection on the individual sensor signals.

7.3.4 Improved Hardware Implementations

• Increasing the resolution of the analogue to digital conversion of the piezos willimprove the ability to differentiate between a beginning of a damp and a light hit.

• To avoid additional processing and trade-off between detection of damps and hits,it would be more advisable to use a sensor type that supports ‘DC force’ detection,such as strain gauges (as suggested in chapter 5).


Figure 7.11: Mechanism for dropping a ball from a specific height at a certain locationon the pad

Chapter 8

Sound Generation

This chapter covers the production of sounds from the electronic timpani. Details ofmeasurements made on timpani on the timpani the anechoic chamber are explainedand proposals for future experimentation are made. The complete dataspace creationprocess is then described.

Two very different modelling approaches, a data driven learning approach and the useof Wavetable Synthesis, are compared. Finally the prototyping of the sound generationmodel in presented.

76

Chapter 8 Sound Generation 77

8.1 Anechoic Chamber Recordings

8.1.1 Purpose of Experiment

The purpose of the experiment was to make many recordings of how the timpani soundsto the player when struck and played in different ways. A complete map can then beconstructed, such that the sound is known for a given pedal position, strike position,and hit strength. These were the key input dimensions as defined in the project aims.This map could be extended to include the effect of different playing techniques such asdamping, glissando and rolls. From this, the sound of the real timpani can be replayed,learnt or mathematically modelled.

Microphone recordings should be made at the player’s head position; the electronictimpani is more likely to be used for practice and teaching purposes, rather than as aperforming instrument. If scope allowed recordings could be made in other positionsto give the electronic timpani more versatility. For this experiments only one record-ing position will be used. Whilst in a real practice/teaching situation there would bereflection from walls, floor and ceiling, the recordings obtained by this method shouldbe independent of their surroundings. If the electronic timpani were to sound to thelistener as though it were in an particular environment, this would be applied in theform of a filter applied to the ‘pure’ recordings.

All possible combinations of input dimension permutations should be covered (such thatthe total number of recordings needed would be the number of steps in each variablemultiplied together). It is possible that for a machine learning approach, not all thecombinations would be necessary. Instead a selective range (including the corner points)could be used.

8.1.2 Method

Having set up the equipment (fig. 8.1), the following method was used to obtain therecordings (a photograph of the anechoic chamber experiment can be found in AppendixH.2):

1. The timpani drum skin was marked with 8 positions using a water-based markerpen, linearly from the centre to the rim (position 1 in the centre, position 8 on therim).

2. All recordings were made at a 48kHz sampling rate using the DAT.

3. The gain on the recording amplifiers was adjusted such that the all but thestrongest strikes would not clip, using the clip indicator LED’s. For the strongeststrikes the gain was decreased by 10dB. The gain on the near-field channel was


Equipment S/N Used ForB&K Type 4165 ISVR 1297135 Player’s Ear (Left Channel)B&K Type 4133 ISVR 489092 Far Field (Right Channel)

B&K Measuring Amp Type 2610 ISVR ‘ICS’ 0132 9200 Left ChannelB&K Measuring Amp Type 2125 ISVR Rayleigh Right Channel

Aiwa DAT HHB1 Pro ISVR 0082 ‘Teaching’ RecordingPower Supply for DAT ISVR ‘Teaching’ 0085 DAT PSU

B&K Sound Level Meter ISVR ‘Teaching’ n/a Verify Strike levelMic Stands x2 ISVR ‘Rayleigh’ n/a Position Mics

Sound Level Meter Stand n/a Support SLMPremier Timpani (28” & 25”) ‘Nuffield Theatre’ Testing

Table 8.1: Equipment Used

Figure 8.1: Equipment Set-up in Anechoic Chamber

-10dB on the input and +10dB on the output. The far field channel had -30dBattenuation, as the microphone type used was more sensitive.

4. The DAT gain was set to the middle of the range (it was suspected that the DATrecorder was a significant source of noise).

5. The sound level meter (slm) was set to peak-hold, to provide an indication of thehit strength. If the level appeared significantly lower or higher than expected, thenthe strike would be repeated.

6. Using the 28” timpani at the lowest frequency, the timpani was struck by the sameperson at each of the positions marked on the drum skin. The player judged thesame strike level for each position. This was first done at hit strength 1 out of 5 (5


being the hardest hit that a timpanist would be expected to normally use). Thesteps in between would be judged to be linearly increasing, both by the player andconfirmed by the sound level meter.

7. Each of the positions were struck, once for each hit strength level. A second takewould be used if the recordings were invalid for any reason. When each of the hitstrengths had been recorded the pedal would be moved to the next position forthe next frequency step.

8. The lowest frequency is at the highest pedal position and the highest frequency atthe lowest pedal position. Five frequency steps were used using linear positions onthe tuning gauge on the side of the timpani. (e.g. ‘frequency 3’ is in the middleof the tuning gauge)

9. The 25” timpani was then recorded in the same way as the 28”, except that onlythe highest and lowest frequencies and only 4 positions were used as there wouldnot be time available to complete the full set.

10. Finally as many examples of rolls, glissando, multiple hits and other playing tech-niques as possible would be taken, time permitting.

The creation of a mechanism to produce repeatable strikes at controlled hit strengthswas considered, but rejected due to time constraints. An alternative would have been tohave an experienced timpanist striking the drum several times, with an accelerometerattached to the mallet so the exact velocity of the mallet head could be determined.The closest match to the required hit strength level could then be taken from the set ofstrikes.

The construction of a mechanical damping mechanism to mimic the way in which atimpanist damps the drum with his hand would be an ambitious task, and may not beas accurate as the use of an experienced timpanist.

8.1.3 Conclusion

It was initially intended that the recordings taken would be a prototype set that could beused to understand what would be needed for the electronic timpani. Initial experimentson the modelling of the sound would be possible, with the intention that a better set ofrecordings would later be taken when the precise requirements of the experiment wouldbe better understood.

It is ironic that the very aim for the project, to create an affordable portable device,would become most evident during this experiment. Due to the limited availability of anytimpani drums and the need to insure the timpani against damage during transportation,


Figure 8.2: Premier Concert Timpani with strike position marked

the timing of the experiment was out of the group’s control and the opportunity to repeatthe experiment did not arise.

During the use of the ISVR’s anechoic chamber, significant problems with externalambient noise were experienced. Whilst the chamber has an impressive attenuationthrough its walls (approx. -60dB SPL), if there are noise events external to the chamber,for example at 100dB SPL, then the noise will be present in the chamber at 40dB.(Noise events above 100dB SPL are easily generated in transmission loss testing in thereverberation chamber adjacent to the anechoic chamber.) The noise events present atthe time meant that many recordings had to be abandoned and the process of collectingwas considerably lengthened. It is also possible that some of the recordings contain noiseevents that were not spotted during the experiment.


8.1.3.1 Quality of the Recordings

The recordings obtained formed a reasonably exhaustive set in terms of the three mainvariables: frequency, position and hit strength. However, it was noted that variationsin the hit strength were less predictable than variations in the frequency or position.This is to be expected in part due to the way in which the hit strength levels generatedin a very qualitative rather than quantitative manner. However because of this, it isnot possible to determine if there is an inherently unpredictable nature in the soundproduced a constant strike velocity (perhaps due to minor changes in the trajectory orhand-mallet interaction). The fact that a hit strength level recorded at one frequencycannot be directly compared to a hit strength level at a different frequency means thatthe recordings cannot be used with full confidence.

The recordings have a noise floor that is close to -50dB, which is reasonable for mostpurposes, however as the dynamic range of the timpani is in excess of 100dB, less noiseis ideally necessary. The large dynamic range of the timpani may present itself as asignificant problem when finally replaying on either headphones or loudspeakers. Forexample, if the volume is set such that the loudest parts are comfortable to listen to andwithin the range of the equipment, then the quiet sections may be virtually inaudible.

Whilst checks were made throughout the experiment to make best use of the dynamicrange and to check for clipping, a degree of clipping is present on a number of therecordings. It would appear that warning indicators on the equipment did not respondquickly enough and therefore it is not a reliable method of determining if clipping isoccurring.

8.1.3.2 Recommended Changes

The experiment did highlight areas that should be changed if the experiment were to berepeated:

• More timpani sizes

The opportunity to make recordings from different size timpani was not available.Only a complete set for the 28” timpani could be made.

• Use of accelerometer

Fundamentally in the experiment, a quantitative measure of the hit strength iscrucial for correct modelling of the sound of the timpani. It was not possible toacquire the equipment given the short notice of the experiment.

• More hit strengths

The nature of the sound produced appears to alter most significantly with thevariation in the strike velocity. With more steps a better model will be produced.


• Tuned timpani

It was suspected that the timpani did not have correct tuning, particularly giventhe movement of the timpani and their susceptibility to rapid de-tuning.

• Experienced timpanist

An experienced timpanist would be able to tune and play the timpani as describedin the above section (8.1.3.1).

• Better SNR

Given the extremely large dynamic range of the timpani, a low noise floor in therecordings is essential.

• High quality DAT

It was suspected that the DAT recorder was a significant source of noise.

• Quiet chamber times

During night time periods the ambient noise around the anechoic chamber signifi-cantly falls. Recordings below 0dB SPL can be made in the chamber at the correcttime.

• Playback amplifier and headphones

The ability to listen to the recordings, directly after they have been made, is highlyuseful. It would also enable a verification of the presence of clipping in recordings.A good quality amplifier and headphones would be required.

• Further play technique experiments

Few ‘play-type’ recordings could be made during the experiment (e.g. damping,rolls, rim shots, glissando). Such recordings would be very useful for modellingthese features in the electronic timpani. Perhaps an additional variable for damp-ing could be added to the ‘map’ of recordings.

• No other timpani in the chamber

Other timpani in the chamber can be excited by the acoustic pressure waves gen-erated from the timpani being recorded. Re-radiated signals could be picked upon the measuring microphones.


8.2 Wavetable Synthesis

Wavetable Synthesis in its basic form simply stores waveforms of the entire note of aninstrument in memory, which can then be played back with pitch shifting to producedifferent notes. It is the most commonly used form of electronic musical synthesis.Usually for modern systems there will be several notes recorded for a given instrument(multi-sampling), for example one per octave is needed to reproduce a reasonable pianowithout obvious jumps. A degree of pitch shifting is almost always necessary, as memorydoes not permit every note on an instrument to be stored.

Looping, enveloping and filtering of these stored waveforms can further the ability to‘play’ an instrument and provided expression. Expressivity is defined in as “the variationof the spectrum and time evolution of a signal for musical purposes. That variation isusually considered to have a deterministic component and a random component.” (ref.(39)) The deterministic element is taken as being that controlled by the user during theperformance, for example hitting a piano key harder produces a ‘brighter’ note. Therandom component is the change that is not possible to control.

Storing different parts of the note gives the ability to change the duration of the noteand the nature of the way in which it has been played. For the sustain or ‘ringing’section of a note, a single period of the note may be all that is stored in the wavetablememory. Storing the attack of an instrument is important, as documented in section2.1.1. Figure 8.3 is a recognized representation of a standard envelope form to each noteand consists of attack, decay, sustain and release. Looping is required for the sustainportion of the note. Each section of the envelope may be stored in the wavetable, orsome of the sections may share the same memory array but are used with a differentamplitude envelope. Envelopes are not usually complex, unless used in very specificcircumstances such as the electronic reproduction of a piano (which is not designed tosound like any other instrument).

Figure 8.3: Wavetable Envelope

• Looping


Looping should include many periods of the waveform to give a note a naturalsound; one might refer to this as making the note “animated”. Usually at least100 periods of the waveform may be used in a good quality wavetable reproduction.

• Amplitude Envelope

Amplitude envelope variation is usually a function of the velocity with which theinstrument has been played. The final waveform may be reproduced by multiplyingthe waveform in memory, by a time varying amplitude envelope.

• Filtering

Filtering is used to produce further effects on the note, for example tremolo. Manysamplers in use today have 1 to 4 pole ARMA filters (Auto Regressive MovingAverage), these can be used to create spectral modifications in the time domain.Typically a filter may be a low pass filter with adjustable Q or resonance.

• Digital Summation

For a device to support many notes playing at the same time there must be severalchannels. The number of channels corresponds to the number of notes the devicecan support; this is often referred to as the polyphony of the instrument. Channelsneed to be added together before being passed through to the digital analogue filter.To avoid ‘word growth’ when channels are added together a scaling rule is usuallyapplied, often of the form 1/

√N . This scaling is appropriate as the signals are

usually uncorrelated.

8.3 Pitch Shifting

There are two forms of pitch shifting; asynchronous pitch shifting and synchronous pitchshifting. The former is far simpler to implement but gives less control over the results,this methods effectively alters the playback speed of the signal by adjusting the samplingrate in the digital to analogue converter (DAC). Adjusting the sampling rate is simple,but can only be implemented on a ‘per channel’ basis. In most applications it is usefulif the data has a fixed sampling rate at the output, where signals need to be combined,as they must all have the same sampling rate. This method is termed ‘asynchronous’as each output channel must run at a different speed. However if the length of therecording is not a concern this form of pitch shifting can have little effect on the qualityof the signal.

Synchronous pitch shifting is necessary if the length of the signal should not vary pro-portionally with the rate of pitch shifting. As this method is implemented using samplerate conversion algorithms, accessing wavetable memory at regular time intervals is morelogical. Also digital summation, and mixing of channels is possible for post processingwith a single data stream. However, quality issues arise if the conversion algorithms arenot carefully chosen. To summarise:


Asynchronous

• Requires a separate DAC per channel

• Can not digitally mix channels (therefore no post processing is possible)

• No inherent artefacts, so long as it is of sufficient quality

Synchronous Pitch shifting

• Many different methods of sampling rate conversion algorithms

• Memory is read at regular time slots

• Digital summation or mixing of multiple channels possible

Notes con only be shifted by a certain amount before they sound unnatural. For record-ings that have significant time domain features, such as percussion instruments, pitchshifting can become quite objectionable (39). For this reason in particular, pitch shiftingthe attack of a note is likely to create more problems than shifting the ‘ringing’ part.

8.3.1 Zero Order Hold / Linear Interpolator

The simplest form of sample rate conversion uses a zero order hold interpolator ((39)).If one considers a waveform is stored in an array denoted by Wavetable[n], where nrefers the location of the datapoint in the array. Also we define a variable Offset, whichhas both an integer and a fractional part, representing the current offset into the array.Then for output datapoints x[n] for each index:

x[n] = Wavetable[IntegerPart(Offset)] (8.1)

During playback the datapoint in the Wavetable[n], may either be dropped or repeateddepending upon the rate at which the Offset is being decreased (fig. 8.4). The waveformwill be shifted up in frequency if the Offset value is incremented by more than 1.0 anddown in frequency if it is less. For example, a value of 2.0 would represent a doublingof the frequency.

This method can be greatly improved by the use of linear interpolation. This uses thefractional part of the offset to calculate the value of the new datapoint. The formulanow takes the form:

x[n] = Wavetable[IntegerPart(Offset)] ∗ (1− FractionPart(Offset))

+Wavetable[IntegerPart(Offset) + 1] ∗ FractionalPart(Offset)) (8.2)


8.3.2 Looping

More complicated forms of synchronous pitch shifting can be implemented if the arrayis read continuously in a loop, that is, when the read point is at the end of the arrayit reads from the start of the array. The read and write points to the array are inde-pendent of one another and therefore move around the loop at deferent speeds, if thearray is read faster that it is written to, then sections of the original waveform must berepeated (8.5). Similarly, if the writing is occurring faster that the reading, sections ofthe waveform are neglected. The problem with looping is that a discontinuity occursas one ‘pointer’ overtakes the other. Truncated signals often have a characteristic ‘belllike’ sound, whereas gaps in the signal have a characteristic buzzing sound. Severalmethods have been used to reduce this problem, the simplest being to fade across thediscontinuity. This effectively reduces the amplitude and extent of the additional fre-quency contribution formed by artefacts. Clearly this process requires significant extraprocessing.

8.3.3 Waveform Based Pitch Shifter

A waveform based pitch shifter detects the pitch of a signal and separates the periodinformation from this, so that the sections of recording that are repeated or deleted arevaried in length appropriately. This technique tends to force the discontinuities formed tocontribute only to the existing harmonic spectrum, so that it is better masked. Howeverit is very difficult to implement this method if there is not a clear and exclusive tonalcomponent. A timpani waveform would be unsuited to this method. Non-harmonicfrequencies of the principle component cannot be dealt with.

8.3.4 Separate Source/Filter Pitch Shifting

This technique involves separating a signal into source and filter components. The sourcecomponent can then be shifted independently of the filter component. For examplespeech synthesis uses this technique. The part of the speech that gives the informationis stored in the filter part and represents the movement of the mouth, tongue and lips.The source component represents the rest of the vocal tract including the voice box.This is a powerful technique as the formants in the signal are not pitch shifted andtherefore the resultant signal is more natural sounding.

Where the two components are generated separately this technique, is effective and canbe easily implemented. If this is not the case, adaptive inverse filtering is necessary toseparate the two components. This method would require a high processing althoughit is possible that in this project the inverse filtering could be completed off-line. The


dataspace would contain the deconstructed signals, and therefore the processing require-ment would be significantly reduced.


Figure 8.4: Waveform from a Zero Order Hold Interpolator

Figure 8.5: Pitch Shifting using a Loop Array


8.4 Data Driven Modelling Approach

It is possible to abstract timpani sound generation to a dimensional-mapping machine-learning problem. When the input variables are considered, they fall neatly into twogroups: those that are related to individual strikes of the skin and those that can varycontinuously.

Strike related

• Hit strength

• Hit location (Polar)

• Pedal position at time of strike

• Damping level at time of strike

Non strike related

• Pedal position

• Damping level

If just the strike related variables are considered, a mapping could be found betweenthe output waveform and the input variables. If the input and output are considered asvectors:

s =

str

pos

pedal

damp

(8.3)

W = [ t0, t1, t2, ..., tn−1, tn ] (8.4)

W = f(s) (8.5)

It should be noted that n is the number of data points in an output sample. For a 15second sample at 44100Hz this would be 661500, representing a very highly dimensionaloutput space.

There are several techniques available to perform this kind of conversion. Two key issuesshould be considered.


1. This process will be implemented in real-time and must therefore be achievablegiven the system’s processing constraints.

2. This system will have to use a data set to fit the mapping, which will inevitablycontain some level of noise. The model should be noise tolerant, and not over fitthe model (so that the noise becomes a feature).

Support Vector Regression may satisfy the second condition (if not the first). It wouldnot be feasible to fit a model for every data point in the output vector, so some methodmust be used to reduce the size of the output vector (output space).

8.4.1 Principal Component Analysis

Principal Component Analysis is a statistical method used to reduce the dimensionalityof a vector without losing features. It is a reversible linear transform that can be usedto project the output data into another space. This is achieved by multiplying it with aset of orthogonal unit vectors.

The output space, as an array, is first adjusted to a central origin by finding the mean ofall the output vectors and subtracting that from all of them. It is then multiplied withits own transform. The eigenvectors and eigenvalues of this array are then calculated andsorted. These eigenvectors are by definition orthogonal and represent a new space. Theobjective with this process is to identify which are the key eigenvectors by disregardingall those with relatively low eigenvalues. Assuming that the output space could bereasonably remodelled using only a low number of eigenvectors, it may be possible toreduce the output space from 661500-dimensional to, say, 20-dimensional. It may thenbe reasonable to fit a model for those dimensions.

8.4.2 Implementation

Due to project time constraints, a machine learning generation technique has not yetbeen implemented. The system structure is designed to allow later implementation withminimal redesign. It should be noted that this system does not provide a method fordealing with those inputs that can vary after the strike occurs.


8.5 Dataspace Creation

8.5.1 File Index

Having spliced the recordings from the anechoic chamber, it was necessary to indexthem. This task was done using Matlab. Each recording existed as an array in a single‘.mat’ file with a name corresponding to the size of timpani, frequency, hit strength,position and take number for each hit (e.g. m1f1s1p1t1.mat). The edited recordingsand the original ‘.wav’ recordings are included on the project CD. Certain parametersneeded to be ascertained for each recording:

• Size:The total number of datapoints in the array. If the recordings need to be the samelength (perhaps necessary for the learning approach to the modelling) this wouldhave to be the length of the longest recording. It is also useful to know how longthe recordings will ring for.

• Clipping:Some method of determining whether or not any clipping occurred.

• Hit strength:An objective measure of strike force was not generated at the time of the recordings,so if the recordings can provide the data it will be a useful resource.

• Noise:A measure of the noise in each recording would be more useful than an overalllevel. If the signal-to-noise ratio were too low it would create problems to any‘learning’ approach to the modelling.

• Frequency:The precise frequency could be determined from the recordings, as it was notmeasured during the experiment.

Other corrections to be made included:

• Offset adjustment:It was observed that there was a minor DC offset in the mean value. Its origin isunclear, but it was easily removed. [offset.m]

• Gain adjustment:Before any quantification of the hit strength could be made, it would be necessaryto adjust the gain of some of the recordings. (When recording the higher strengthhits, the gain had to be reduced by 10dB to avoid clipping and make better use of


the dynamic range, as described in section 8.1.2). It did not make any differencewhether the level of these was increased or the level of the rest of the recordingsdecreased, as they would all eventually be normalized to 16bit signed integers.[gain10up.m]

The complete index can be found in Appendix L. The code for these functions is onthe project CD [makefileindex.m], along with the code for the other parts in this sectionshown in square brackets.

8.5.2 Clipping

Unfortunately a significant number of the recordings contained clipping. A functionwas written to attempt to identify the recordings where this may have occurred, byflagging adjacent datapoints with the same value within 95% of the limiting value. Anyrecordings with audibly detectable clipping were ignored. [clipping.m]

8.5.3 Noise

A measure of the noise was taken to be the RMS value of the last half-second of eachrecording. It is assumed that during this part of the recording, ringing of the note hasdecayed significantly such that these datapoints represent background noise only. [Usedin: findend.m, makefileindex.m, offset.m, singleindex.m, tailandcut.m and trim.m]

8.5.4 Frequency of Recordings

Frequency is determined from the frequency spectrum of each recording in the periodafter the decay of the initial transients.

The frequency of the recording should correspond to the second sharp peak in the spec-trum. The fundamental frequency or ‘01’ mode of the timpani is lower than the perceivedpitch (as explained in section 2.2.1, this is the ‘missing fundamental’ phenomenon). How-ever in practice this is slightly harder to identify. For those recordings correspondingto positions close to the centre of the drum the ‘01’ peak is strong and the ‘11’ peak isconsiderably reduced, whereas for other positions the ‘01’ peak is difficult to identify.Therefore a routine had to be created that found the first several peaks. The peakcorresponding to the ‘11’ mode could then be identified manually using common ratiosdetermined by previous research in table 2.4.

The Matlab power spectral density (PSD) function was used to generate the frequencyspectrums. A 48k window was used to give a 1Hz frequency resolution, however several


Figure 8.6: Example of mode lines found

other windowing sizes were used to confirm that the results were obtained were consistent(i.e. did not contain aliasing). [frequency.m]

8.5.5 Hit Strength of Recording

It is not possible to compare the amplitude of the recordings from the same hit strengthlevel. For example, a ‘hit strength 4’ at ‘frequency 4’ is not at the same level as a ‘hitstrength 4’ at any other frequency. This is most likely due to the way in which therecordings were made: with no reference hit level, and an indirect measure of the hitstrength each time.

Secondly, this assumes that the amplitude of the recordings is directly proportional tothe hit velocity. There is no one correct way of measuring the level from the recording,so the RMS average of the first 100ms was used as this gave the a reasonable correlationwith the sound level meter readings.

Finally, as was first noticed during recording, the level dropped with increasing distance


from the centre of the timpani head. Comparing the spectrogram of a centre hit (fig.8.7) with the spectrogram of a quarter hit (fig. 8.12), shows how the higher frequencycontributions increase towards the centre of the head, which helps to identify the causeof this phenomenon.

Figure 8.7: Spectogram of a centre-hit

It is preferable that recordings should not be modified to preserve this position depen-dence. In order to compare values, a method was devised to identify which recordingswere inconsistently higher or lower than the general trend:

1. First the average value from the eight positions, for a given frequency and hitstrength, was taken.

2. Then the ratio of this average value over the actual value would be plotted foreach position (fig. 8.8).

3. These plots show how the level varies linearly with position for a given frequency.The gradient of this line, however, is not the same for each ‘frequency’ and ‘hitstrength’.

4. Using the general trend a corrected measure of the ‘hit strength’ could be formed.[hitstr.m].

5. Where the difference between the average level and the corrected level was consid-ered too large, then the recording could be corrected.

Figure 8.9 shows the value at ‘position 4’ lies outside of the expected range (using atolerance of 20%). Note that by this method only recordings with spurious levels arecorrected.


1 2 3 4 5 6 70.2

0.4

0.6

0.8

1

1.2

1.4

1.6

Position

Rat

io o

f Ave

rage

Lev

el o

ver

Act

ual L

evel

Position Dependence

y = 0.1466*x + 0.176

data 1 linear

Figure 8.8: Linear correlation between Position and ‘Hit Strength’

The method by which the level should be raised or lowered is considered in detail insection 8.6.3 (interpolation of hit strength). The conclusion is that a basic amplitudeadjustment makes a reasonable approximation. However, it has been observed that thelistener is less likely to notice that a recording has been changed, if it has been shiftedfrom a different frequency. Also, as two takes were made during recording (usuallybecause the first was considered incorrect) there were several options by which to correctthe hit strength measure. The order of preference for correction takes the following form:

1. Use Take two: The second takes were usually closer to the expected value.

2. Frequency: Using a recording by shifting the closest recording with the same‘position’ and ‘hit strength’ was preferable to adjusting the amplitude. [checkstr-freq.m]

3. Low Level: For those recordings with very low levels, the higher of the twotakes would be used or amplitude shifted down from the ‘hit strength 2’ recording.[checkstr.m]

4. Level: Usually corrected to the expected value, unless inconsistent with adjacent


1 2 3 4 5 6 70

1

2

3

4

5

6

Position

Cor

rect

ed V

alue

Comparison of Hit Strengths

Figure 8.9: Corrected value vs position. ‘Position 4’ value lies outside expected range

recordings (in this case the level was adjusted to the average between adjacentrecordings).

If the initial data had been collected in a more controlled manner, the measure of thehit strength would not need to be taken from the recordings themselves.

8.5.6 Trimming

Recordings must start as soon as they are played. They should also start initially witha zero value so that clicks are not created as the sound card plays the recording, due todiscontinuities. The start of the recording is taken to be the first datapoint that exceedsa certain noise threshold. By inspection, events in the noise generally do not exceed fourtimes the RMS noise level.

A simple loop would search through the recording until a datapoint was greater than fourtimes the RMS noise level. A new recording would then be constructed by backtrackingby a single datapoint and setting its value to zero. [trim.m]


8.5.7 Tailing

Two problems had to be overcome to implement the correct tailing of the recordings:firstly, finding the end of the recording and secondly determining what envelope shouldbe used to tail it to zero. There is no ideal way by which the recording can be tailedas the timpani will continue to ring infinity, although the recordings must have finitelength. Therefore, from the point at which the ringing is no longer audible, the recordingmust be tailed to zero. If a ‘learning’ approach to the modelling were employed, themethod of tailing should be considered carefully as it may introduce artefacts into thedataspace. A linear envelope was created to tail the recordings with a length dependentupon the total length of the recording (fig. 8.10).

The end of the note was detected using a routine to search backwards through therecording, until a number of datapoints exceeded a set level within a given time period(based upon the RMS noise earlier determined). Although this eliminated randomnoise, unwanted sound events (such as a audible knock) would cause an erroneous enddetection. Another routine examined this end point to differentiate knocks from the endof the note. [tailandcut.m]

Figure 8.10: Tailing


8.5.8 Forming the Dataspace

A single large array was created by combining the individual recordings. When compilingthe dataspace an index would be created, giving the start point and length of eachrecording in the array. The dataspace would also contain any information required toquantify the array, including the number of steps in each variable (hit-strength, positionand frequency), and the normalised tables of these steps. It also includes the ‘frequencymap offset’, which is used to calculate the frequency shift needed when re-sampling. Thedescription of the dataspace and the precise order of this information is given in section9.4. [create.m and trans.m]

8.6 Model

8.6.1 Recording Generation

Generation was formed in two parts. Selecting which recording in the dataspace to use,and generating a new waveform by manipulating it. It is intended that the dataspaceand the sound generation code could be independently replaced without changes beingmade to the other.

The generation responded to three inputs, namely: frequency, strike position and hitstrength interpolation. Damping (section 8.7.2) and glissando (section 8.7.1) are alsoconsidered but must reside in the channel filter. Throughout this section, code wasimplemented in Matlab first, to verify the principle method and to check that it wouldwork correctly with the dataspace. [model.m]

8.6.2 Frequency Interpolation

The dataspace contains recordings at five discrete frequencies. It was necessary to pitchshift the closest of these to the desired frequency, as governed by the pedal position. Asexplained in section 8.3, methods of pitch shifting essentially fall into two categories:asynchronous and synchronous. Asynchronous pitch shifting is not an option as it mustbe possible to have more than one note ringing at the same time.

It was not necessary to program, by whatever means, different methods of pitch shiftingin order to test them. Many recording/editing programs, such as Cooledit and Gold-wave, contain these functions with reasonable documentation of how they have beenimplemented. Conducting tests proved that looping methods (section 8.3.2) create anunpleasant sound due to the discontinuities occurring at the end of the repeated/cutsegment. Whilst careful selection of the length of segments created, in order to matchthe pitch of the recording improved this, results were still far worse than those achieved


by the simpler methods. Also these more complicated methods would have been lessefficient, given the size of the recordings this would increase latency.

The pitch shifting method implemented, is based upon a form of linear interpolationresampling (section 8.11), but is more efficient because only a single multiplication isused. If n is the index at which the datapoint is to be created from the original recording,then for every n from one to the length of the recording in the dataspace, we take thedatapoint from the recording either side of the index n to calculate the value of the newdatapoint at n. The integer values in the recording below the index corresponds to the‘floor’ of n.

newdata = (n− floor[n]) ∗ (wavedata(floor[n] + 1)− wavedata(floor[n]))

+wavedata(floor[n]) (8.6)

Figure 8.11: Linear Resampling

Pitch shifting by this method introduces negligible degradation of sound quality forsmall changes in pitch. The maximum amount of pitch shifting the recording is likely toneed, given that there are five discrete frequencies almost linearly covering the frequencyrange, can be calculated at around 5-6%. However, recordings shifted by the whole rangeof the timpani pedal (approx. 50%) still sound reasonably consistent to the all thosewho listened. While the discerning ear would be able to tell the difference this, formeda good starting point. It is possible to play a note on a timpani drum at one end ofthe scale and shift it to the top (although an unlikely method of playing normally) andtherefore this simple method could be quite effective. Therefore the same method ofpitch shifting was used in the generation part of the program and the channel filter part


of the program.

8.6.3 Hit Strength Interpolation

With a little experimentation, it was clear that it would be more difficult to createconvincing results with hit-strength interpolation. The ear could be better deceived ifthere were more discrete steps in hit strength. In this scenario one may not need tointerpolate between them. The differences between two different hit levels are moreeasily quantified in terms physical changes in the system. It is understandable thatif more energy were put into the system, non-linear effects would be more prominent(e.g. wrinkling of the timpani membrane close to the impact due to its inertia). Interms of the differences in the waveform created, it is evident that this would increasethe contribution of the higher harmonics and in-harmonic higher frequencies in general(those more associated with traditional drum sound). The duration of the note is alsolonger. A spectrogram of a recording beautifully illustrates this (fig. 8.12).

Figure 8.12: Spectogram of strike at ‘Position 4’

At first a somewhat ‘blind’ approach to this problem was proposed. Identifying a generaltrend in the increase in level and duration of certain harmonics as the hit strength isincreased, may make it possible to make a lower recording sound similar to a higherstrength recording and visa-versa. This could be implemented in the form of timevarying FFT filters or more crudely, with narrow band filters to increase or decreasethe contribution from certain harmonic frequencies. This method assumes that all theinformation for a different strength hit is contained within the given recording and thatthe general effect of a transformation in the input produces a relatively simply transformin the output. It is easy to see at this stage, how the prospect of a ‘learning’ approach


to the modelling task becomes attractive and logical.

Experimentation to implement the process described above proved slow and inconclusive.After informal discussion with staff in the ISVR, in particular Dr. P. White, a betterapproach to the task was considered, but on the whole there is no clear solution tothe problem. It is possible that a transfer function between the Fourier spectrum oftwo recordings of different strength could be calculated, however this would not takeaccount of their phase. This would be a particular problem given that the two recordingswould not have the same length. Conceivable methods of dealing with the phase, suchas averaging or using the phase information from the higher of the two hit strengths,would be unreliable. This approach was unlikely to yield results within the time frameof the project. It has therefore been abandoned.

To reduce the audible steps that would be created by only five different levels of hitstrength, a basic amplitude mapping was used. For the most part this proved relativelysuccessful, only creating a clearly audible discontinuity where the dataspace containedreadings that were inconsistent. These problems could be avoided by using a bettercontrolled and more detailed dataspace.

8.7 Damping and Glissando

8.7.1 Glissando

For a single timpani all ringing notes share a common pitch; there is only one skin on atimpani. In the electronic timpani the recordings for the note may have been generatedwith the pedal at different frequencies, and would therefore need shifting by differentamounts. As identified in earlier (section 8.3), pitch shifting the attack is not ideal. Asa range of timpani recordings are used, initial pitch shifting is minimised. However, asthe glissando only effects the ringing portion of the note a greater range of pitch shiftingis acceptable.

Consider two notes are generated one second apart. The pedal on the timpani is de-pressed such that the pitch increases linearly from 100 to 200Hz (fig. 8.13). The firstnote is generated at 100Hz and is continuously pitch shifted upwards. After one secondthis has reached 150Hz and at the same the second note is generated at 150Hz. Aftertwo seconds both notes are ringing at 300Hz, however the first is being shifted by afactor of 3.0 but the second by a factor of 2.0.

Glissando is implemented using the resampling method used in the generation module.This is fully explained in the concise system overview (section 9.5.2.1).


Figure 8.13: Pitch shifting in channel filter

8.7.2 Damping

As with glissando the damping routine must occur in the channel filter. This is becausethe system must remember the amount of damping that has been applied to each ringingnote at any given point in time. If this were not the case, as soon as the damping eventdiscontinued, the waveform generated would return to its previous level. Consider a hitthat is then damped. The damping is released and the note is still ringing but at anattenuated level. If a new hit occurs at this point there should be no attenuation appliedto it.

The damping was first implemented as an exponential envelope by which the waveformwas multiplied. However a more efficient and simpler routine occurs in the presentcode. This simply multiplies the waveform by a cumulatively decreasing factor (eq.8.8). The rate at which the factor decreases is related to the damping value from theContinuousInputTable using equation 8.7.

DampRate = 1− (CurrentDamp ∗ 0.0001) (8.7)

DampV alue = DampV alue ∗DampRate

NewWaveForm(n) = OldWaveForm(n) ∗DampV alue (8.8)


8.8 Implementation

Once the method of sound generation had been selected, it was re-implemented in C.

8.8.1 Data Types

The most significant change was in data type. By default Matlab uses a double datatype to handle all calculations. This is an eight byte long data type with floating pointprecision. Whilst C is entirely capable of handling doubles, it was decided to base soundhandling modules on the short data type. This was done for the following reasons;

• Memory SizeThe program needs to allocate significant amounts of memory to store the datas-pace and the wavetable. These need to be held in system RAM for performancereasons. Data stored as shorts takes up a quarter of the space that the same datawould as a double.

• OutputThe sound card takes short data, and so if any other type were used for processingit would have to be converted before writing to the sound card. This means thatany extra accuracy gained by using the larger data type would be lost just priorto output.

• ProcessingThe processing of integer data types, like shorts, is dramatically faster than float-ing point types. There are parts of the process, like resampling, that currentlyrely on floating point values. It may be possible to optimise these later.

8.8.2 Global Data Structures

To minimise the amount of variables required in function calls, the storage and hardwaredata was all stored in a globally accessible datastructure called DataSpace. As all thedata was accessed via a single struct there was minimal namespace pollution. Althoughthis did allow the software to be developed quickly, it imposed some difficulties whiletrying to de-bug, as it was possible for functions to access and change data that theyshould not. When integrating modules, care was therefore taken to ensure that theyonly read “up-stream” and that they created outputs as expected by other modules.


8.8.3 Testing

As each section was developed a separate main.c file was written. This created a newversion of the program specifically design to exercise and test that part of the program.This was particularly important before threads were implemented, as it was not possibleto run both the inputting and outputting modules on a single thread.

Chapter 9

Concise System Overview

This chapter is a concise overview of the current electronic timpani working prototype.The sections detail hardware, software architecture, input processing, sound generationand dataspace creation.

105

Chapter 9 Concise System Overview 106

Analogue-to-digital conversion

Level adjustment & buffering

PIC microprocessor

Serial port input

Input processing

Sound generation module

Channel combination

Channel filter module

Open source sound output

Piezoelectric transducer sensors Input:

Mallet strikes drum plate

Output:

Sound to amplifier or

headphones

Input: Tuning pedal

Softw

are com

ponents in PC

H

ardware

components

Dataspace

Control

n channels

Strike-related inputs table

(hit location and strength)

Continuous inputs table

(for damping and glissando)

Wave table

Post filter module

Processing

Data storage

KEY

Figure 9.1: Overview of electronic timpani system


9.1 Hardware

The electronic timpani hardware system consists of two separate units: a rigid drumplate with sensor assemblies attached, and an electronic circuit board housed in a plasticcase. The sensor outputs are sampled by the circuitry, and the readings are transmittedvia a serial link to the PC. The circuit diagram is shown in Appendix E.

9.1.1 Drum Pad and Sensor Assemblies

The drum pad is intended to simulate the playing surface of the timpani, with movementdetected by the sensor assemblies. The plate is an aluminium honeycomb-structure sand-wich panel of diameter 340mm and is struck by the timpani player with mallets. Threesensor assemblies support the plate from underneath, attached equidistantly around theplate circumference. Each sensor assembly consists of a piezoelectric transducer bondedto layers of rubber to it. The arrangement of the layers of rubber is such that the trans-ducer is flexed in a similar mode to that of its normal operation as a sounder, therebymaximising the amplitude of the transducer output signal.

9.1.2 Signal Conditioning

The electrical signals from the transducers are passed into the electronic circuit board,and undergo several stages of processing before the analogue to digital conversion. Thefirst stage is to attenuate the signals using a potentiometer to allow individual adjust-ment. The signals are then buffered to amplify the current, and a level shift takes placeby means of a voltage divider to meet the required input range of the analogue-to-digitalconverters (ADCs).

A commercial electronic keyboard pedal, with modified connections, is used to simulatethe operation of the timpani tuning pedal. The pedal is connected to act as a voltagedivider, giving an output of between 0V and 5V dependent on the angular position ofthe pedal.

9.1.3 Digital Design

Three 8-bit ADCs (National Semiconductor type ADC0804) send values in parallel to aPIC microcontroller (Microchip type 16F871), which provides the requisite flexibility. Itruns at a clock speed of 12MHz and also converts the analogue voltage from the tuningpedal into digital values, using its internal ADC.

The sensor and pedal information is transmitted according to the following protocol:


Start byte

Sensor A reading

Sensor B reading

Sensor C reading

Tuning pedal reading

Sensor A reading

Sensor B reading

Sensor C reading

This protocol is optimised to:

• maintain synchronisation

• minimise possibility of errors

• maximise data transfer rate

This data sequence is transmitted approximately once every 0.6ms to the PC using theRS-232 serial interface, via a level converter and cable. The serial interface runs at115200 bits per second (bps). No data flows from the PC to the PIC.


9.2 Software Architecture

The electronic timpani uses a range of processing and storage modules to perform com-plex real time input processing and sound generation. This section outlines the overallsystem architecture.

9.2.1 Platform

A single PC is used to translate sensor readings (communicated via the serial port)into an audio output. A Linux platform was selected as it offered good low-level accessto hardware and processes scheduling facilities. Where possible standardised functionsand libraries (notably POSIX) are used to facilitate porting to other operating systemsat a later date. The real-time software is implemented with C (flexible and efficientprogramming language).

9.2.2 Structure

The software is divided into three layers; hardware, global storage and processing layer.The storage layer is used to store the intermediate results created by the separate pro-cessing modules without them needing to call each other’s functions. This helps modu-larisation and also allows the program to be multiply threaded.

There are five main data structures provided:

• StrikeTable

The strike table records information that relates directly to individual strikes. Thiscurrently includes strength, radial distance and pedal position at time of strike.This could later be extended to allow for multiple timpani and mallet types.

• ContinuousInputTable

This table records values for the those inputs that vary between strikes. Thiscurrently includes damping level and pedal position.

• WaveTable

This table contains a set of waveforms which hold the output of the generationmodule. This table is queried by the channel filter to created sound fragments.

• ChannelBuffer

The sound fragments created by channel filter are held in this buffer before it iscombined into the SoundOutputBuffer.


• SoundOutputBuffer

The SoundOutputBuffer is passed to the post filter module before being written tothe soundcard. It should be noted that the post filter module is currently unused.

9.2.3 Threading

In order to ensure that the hardware interfaces are dealt with at the correct rate, eachis given a separate thread. This means that the program effectively executes at threeseparate points concurrently. This also allows the output thread to begin playing awaveform before the generation thread has finished creating it.


9.3 Input Processing

9.3.1 Description

The input processing module scans the information provided by the PIC and extractsdamping and strike information. The hit strength and radial position of these strikesare then calculated, and provided to the sound generation part of the program.

9.3.2 Operation

Once the appropriate initialisation is performed, the data output from the PIC into theserial port of the PC is read in frame by frame. A frame is defined as a set of piezovalues and the pedal value.

The frames are stored in a buffer and are then subjected to a running length averagingfilter, that attenuates high frequency noise. During the initialisation process, the zero-volt offset is measured by averaging 1000 readings while the pad is not being hit. Thenoise level is also estimated at this stage. It is taken to be the maximum value occurringduring this initialisation period.

Detecting the occurrence of a strike or damping requires the detection of peaks withinthe sensor readings. This is achieved by finding an instance where the first derivative inthe signal is zero and the second derivative is negative.

The differentiation between an onset of damping and a strike is performed by measuringthe duration of the ‘strike pulse’. If this exceeds a threshold, the event is perceived asdamping. As the profile of the first few samples of damping strongly resemble very smallstrikes, these need to be rejected.

The output variables for strength of damping and strength of strike are generated bycalculating the mean sensor value and then normalising it from 0 to 1.

Positional information is extracted by calculating the magnitude of the sum of vectorsassociated with the three sensor values. Again this calculation is based on the assumptionthat the sensors behave linearly with respect to distance - as this is not the case, theabove calculations are subjected to linearising transformations.


9.4 Dataspace Description

The sound generation module uses a range of pre-recorded timpani sounds stored ina dataspace, which is saved as a file called ‘dataspace.dat’. This is a file containingall recordings, plus additional information to index and quantify the dataspace. (Thedataspace.dat file is compiled with trans.m on the project CD.)

200 recordings are stored in the dataspace, consisting of:

• 8 radial positions

• 5 frequency steps from linear pedal positions on the timpani using the tuning gauge

• 5 hit strength levels, judged by hand and verified with a sound level meter (spuriouslevels for individual hits corrected)

All recordings have been trimmed such that the value of the first datapoint of eachrecording is zero. Each recording also has a linear taper to a zero value from the endof the recording (where the end is the point at which the ‘ringing’ falls below the noiselevel). The data is sorted as 16-bit signed integers, scaled so that the highest value inall recordings is at 90% of the maximum (32768). There is a small degree of clipping onsome of the recordings (see file index J).

Dataspace.dat is constructed in the following order:

1. Three dimensions: The number of frequency steps, followed by the number ofhit strengths and then the number of radial positions. (Stored as shorts)

2. Frequency map offset: Value used when calculating the correct frequency shiftneeded for pitch shifting. It corresponds to the ratio of the lowest frequency (inHz) to the highest frequency (in Hz) stored in the dataspace. (Stored as a float)

3. Normalisation Arrays: Arrays of the three variables, normalised between 0 and1, in the order of frequency, position, strength. See equations 9.1 to 9.4. (Storedas floats)

4. Index of Recording Lengths: The lengths of the recordings in order. Therecordings are stored in the following order, primary: position, secondary: hitstrength, and tertiary: frequency. For example, the 41st recording would be ‘fre-quency 2’, ‘strength 1’, ‘position 1’. (Stored as shorts)

5. Recordings: The recordings stored consecutively in the same order as the indexof lengths above.


9.4.1 Normalising the Dataspace Variables

The tables of normalised variables are calculated by the following equations. For allintegers, n, from 1 to the number of frequency steps, F , the normalised frequencies are:

nf(n) =(df(n)− df(1))(df(F )− df(1))

(9.1)

where nf(n) is the array of normalised frequencies.For all integers, n, from 1 to the number of hit strengths, H, the normalised hit strengthsare:

ns(n) =n

H− 1

2H(9.2)

where ns(n) is the array of normalised hit strengths. For all integers, n, from 1 to thenumber of positions, P , the normalised positions are:

np(n+ 1) =1

(P − 1)∗ n (9.3)

where np(n) is the array of normalised position and:

np(1) = 0 (9.4)


9.5 Sound Generation

The electronic timpani project attempts to recreate the sound of a authentic sound of anacoustic timpani using digital processing. This section outlines some of the techniquesthat are used.

9.5.1 Sound Generation Module

Normalised values for the frequency, position and strength are read from the StrikeTable.The model determines which recording in the dataspace is closest to these values. Thisrecording is then resampled to match the actual frequency (from the pedal position at thetime of the strike). The shift needed to resample is calculated using equation 9.5, whereFreqMapOffset is the ratio of the lowest frequency (in Hz) over the highest frequencyin the dataspace (in Hz), Pedal is the normalised pedal position from the StrikeTableand nf(closest) is the closest frequency variable in the dataspace. The amplitude is alsoadjusted to the correct level. The resampling uses the linear interpolation method asexplained in section 8.6.2. No adjustment to the recording for the position is made.

shift =FreqMapOffset + (Pedal ∗ (1− FreqMapOffset))

FreqMapOffset + (nf(closest) ∗ (1− FreqMapOffset))(9.5)

9.5.2 Channel Filter Module

In order to implement glissando and damping, each channel has a resampling and decayroutine in the channel filter (section 8.7.1). These are not continuous in real-time on adatapoint by datapoint basis but occur on the ‘packets’ of data that are passed throughfrom the sound generation module to the channel combine filter. As packets are only afraction of a second long, it appears to the player as though these do occur in real-time.With the current ‘packet’ size, steps in frequency and damping are not audible duringa glissando event.

9.5.2.1 Glissando

Resampling uses the same linear interpolation method used in the sound generationmodule, where the shift is calculated using equation 9.5. In this case, the variablenf(closest) is the frequency at which the recording is generated in the sound generationmodel, and Pedal is the normalised frequency read from the ContinuousInputTable toget the current pedal position.


9.5.2.2 Damping

The recordings are attenuated in the channel filter during a damping event. The amountof attenuation depends upon the level of damping applied. The normalised dampingvalue is continuously read from the ContinuousInputTable. Datapoints with the record-ing are then multiplied by a cumulatively decreasing factor. The rate at which the factordecreases by is related to the normalised damping value. (For further information seesection 8.7.2.)

Chapter 10

Project Management

This section details how the project was managed, including task breakdown, resourceallocation, budget and communication.

116

Chapter 10 Project Management 117

10.1 Team Task Allocation

The project was divided into several related, but distinct sections. This allowed teammembers to focus on those areas particularly suited to their skills.

Stephen Emsen:

• Selection and initial programming of PIC

• Handling a serial port using POSIX functions

• Generation of code for interpreting and processing the input to differentiate damp-ing and strike information

Christopher Heal:

• Research into the acoustic behaviour of the timpani

• Creation of the dataspace from the recordings of the timpani

• Development of Matlab prototype code for sound generation

• Project secretary

Richard Sunderland:

• Design of the software architecture

• Sound API interfacing

• Implementation of data storage and access functions

• Coordination and integration of all software components

Robin Willis:

• Construction of drum pad and sensor assemblies

• Design and construction of the electronic circuit board

• Development of programming of the PIC

• Project coordination

All team members researched the hardware for the sensor selection at the start of theproject, and contributed to the discussion of the drum plate/sensor configuration. Theproject report was written and edited with contributions from all members. All memberswere involved in the anechoic chamber experiment.


10.2 Team Resources

Although the team initially had six members, the majority of the project was performedby four. Two members chose to leave the course after the team had been allocated.Adam Johnston, studying Mechanical Engineering, chose to graduate at the end of PartIII and Peter Wood study Electronic Engineering assumed a sabbatical post on theStudents Union Council in November 2001.

Although the creation of a fully working prototype is a significant achievement, evenmore may have been accomplished if the team had more members. The inclusion ofa Mechanical Engineering (or possibly Industrial Design) student would have allowedthe ergonomics and aesthetics of the electronic timpani hardware to have received morethorough attention. Additional team members with programming experience would havereduced the workload on the software developers and allowed other avenues of research,such as the data-driven modelling, to be explored more completely. The extra teammembers would have also contributed to general project duties including report writing.

10.3 Budget

The project budget of £700 was provided by the Faculty of Engineering. This budgetwas to include a project PC and all external hardware. A proposed cost breakdown wassubmitted at the start of the project, but was later adjusted slightly to include an extrahard-drive and transportation insurance for the University’s timpani. Even with theseextra costs the initial budget was found to be sufficient.

10.4 Laboratory Space

Most medium-term group projects require access to dedicated laboratory space so thatequipment can be left correctly configured. Unfortunately both the department (ECS)and the Faculty of Engineering were unable to provide this. The unprompted generosityof the ISIS research group, in their provision of laboratory space, contributed signifi-cantly to this project. The team felt that consideration should be given to the provisionof well-equipped multi-disciplinary facilities.

10.5 Communication

Most formal discussion was performed using a threaded email-list. This allowed oursupervisors and sponsor to keep track of progress. This became especially important


during the period in which our supervisor was abroad. Informal communication, espe-cially after combined lectures, helped with day-to-day organisation of tasks. In the earlystages a dedicated website proved useful for sharing research and links. This websitewas not maintained towards the end of the project because it did not provide enoughbenefit to justify the time required.

10.5.1 Group Meetings

Group meetings created an opportunity for more formal discussions with the projectsupervisor. This was important at the early stages in providing drive, feedback andadvice.

10.5.2 Formal Meetings

Formal presentations and meetings allowed the group to benefit from more in-depth andcritical appraisal, from both a musical and academic stand point.

10.6 Timpani Availability

Some of the university timpani were used during the course of the project in order toobtain recordings. However, the availability was limited because they are in constant useby the Music Department. The team was granted access to them on two occasions. Thefirst, in early December, was used for initial recordings in the Turner Sims concert hall.The second, for two days later in December, were used for more formal recording in theISVR anechoic chamber. For this latter recording session, an insurance policy was takenout to cover the timpani for accidental damage, and the help of the University Securitystaff was requested in order to transport the timpani from the Music Department to theISVR.

10.7 Timpani Player Availability

Initially the team hoped that a close working relationship with the University Orchestrawould develop. This would enable us to continually monitor and improve the ‘lookand feel’ of the electronic timpani. Peter Wood had several good contacts within theorchestra and the team lost these when he left. The now smaller team was forced tomanage resources more judiciously, and as such could not afford the time required todevelop a useful working relationship.


10.8 Breadth vs Depth

With any project there is a trade-off between the number of options considered in detailand the amount of work that can be dedicated to developing the chosen solution. Oneof the project’s key objectives was to produce a working first prototype that could beused as a development platform for future work. As the project had a tight time scale,it was important to identify which components were absolutely necessary and focusattention on those. Input dimensions were prioritised so that the important ones wouldbe achieved first. Wherever possible the system was designed to facilitate extension andmodification at a later date.

10.9 Role Adaption

The team was forced to reorganise its task allocation six weeks into the project. The workand roles that had been allocated to Peter Wood were divided amongst the remainingmembers. Robin’s role as a manager was slightly less important with the smaller teamand he took on a more technology-focused workload to compensate for the missingmember. The team was still determined to achieve the agreed objectives and so thework schedules were not adjusted.

10.10 Software Management

As Robin was not directly involved with the programming, the organisation and man-agement of the timpani software (with the exception of the PIC program) was handledby Richard. The work was divided into three main sections:

• Input Collection and ProcessingStephen Emsen focussed on the two input stages: serial port handling and strikeand damping detection.

• Sound Generation and ProcessingChristopher Heal focussed on sound generation theory and preparation of thedataspace. Those components of his work that were used in the final programwere converted into C by Richard Sunderland.

• Storage, Structure and OutputRichard Sunderland developed and maintained a system of globally accessibledatastructures and the functions required to use them. These provided communi-cate between the processing units. He also handled the initialisation, usage andtermination of the soundcard.

Chapter 11

Recommendations for Future

Work

Although this project has laid a very solid foundation there is plenty of scope for furtherdevelopment. This section outlines some of the ways the project could continue.

121

Chapter 11 Recommendations for Future Work 122

1. Multiple TimpaniTimpani are commonly used in groups of three or more. The system has beendesigned with extensibility in mind and so the inclusion of further timpani shouldnot be difficult.

2. Further Sensor DevelopmentThe system currently relies on piezoelectric transducers for both damping andstrike information. Although it is possible to separate this information in software,this is done at the expense of the accuracy of damping level detection. The systemcould be made more accurate if a set of strain gauges, or similar, were used tomeasure damping directly.

3. Tuning PedalThe commercial keyboard pedal is satisfactory for the prototype electronic timpani.Future versions would require a mechanism to more accurately simulate the actionof a real timpani pedal.

4. Communication MethodCurrently RS-232 based communication is used. This is satisfactory for a singletimpani, but would not be suitable for several. A faster communication standardsuch as USB or FireWire would allow further flexibility in the sensor sample rate.A wireless system would make the system much more convenient to use.

5. Drum plateAlthough the current drum plate operates effectively, it needs to be developed intoa rugged and portable device. Careful attention should be given to the selectionof materials to minimise the sound of strikes on the pad, and mimic the bounce ofa real skin.

6. Hardware resolutionThe current hardware uses ADCs with a resolution of 8 bits. The resolutioncould be increased to improve detection of soft hits. (This would require a fastercommunication method.)

7. Signal Noise ReductionsCurrently the data received by the PC has a significant noise component. Thiscould be reduced if higher precision components were used with a printed circuitboard. Careful signal routing will further reduce noise.

8. Machine Learning Based Hit/Damping DetectionAs an alternative to using strain gauges (which are more expensive than piezos)it may be possible to improve hit/damping detection algorithms using some formof machine learning (such as Support Vector Classification, Neural or NeuroFuzzyNetwork). If this can be implemented effectively then it may make strain gaugesunnecessary.

Chapter 11 Recommendations for Future Work 123

9. Digital Filter Based Input ProcessingResearch into digital filtering indicates that it might provide an effective and robustmethod of separating strike and damping information. Further development andresearch is required to prove this technique and thereby obviate the need for straingauges.

10. Improve Sound GenerationThere are several techniques that may allow a more faithful recreation of a tim-pani’s output. These include neural networks and support vector machine re-gression. As yet this has not been implemented due to time constraints but theplatform could easily be adapted to include it.

11. Improved DataspaceAll of the sound generation techniques rely on some form of dataspace of timpanirecordings, even if it is only for verification of output. The project has produceda viable dataspace for most prototyping purposes, but it may be necessary tocollect a better space, including more sizes and types of instrument. This wouldbe a time-consuming and possibly costly under taking. Some pre-recorded timpanisamples are available for purchase, and may be suitable for producing a dataspace.For example the Ultimate Timpani Library is available from Christian and Laneat a price of $349 (18). This recording contains samples of varying hit strengthbut not varying position.

12. User InterfaceCurrently there is minimal user interface. If the system were to be built aroundan embedded-style device, then even this interface would be lost. There may besome scope for including a dot-matrix style LCD display on each timpani pad unit.This would allow selection of timpani type, size and mallet type, as well as givingbasic diagnostic information.

13. MarketingIt is hoped that this project may eventually evolve into a marketable product. Todate however, there has been no research into its potential.

14. Alternative ApplicationsThe current hardware and software architecture have been designed with flexibilityin mind. Even the prototype is capable of producing a wide range of interesting(and amusing) sounds. Further research into alternative applications would beadvised.

Chapter 12

Conclusions

124

Chapter 12 Conclusions 125

12.1 Success

This project has successfully taken an initial idea through to a working prototype. Theproject provides a stable and well-designed development platform that will be a firmfoundation for future work in this area.

The electronic timpani responds to the four input dimensions defined in the projectobjective. It also responds correctly to the fifth input dimension, namely glissandos.Although the other dimensions (timpani type and mallet type) are not implemented,this could be easily remedied by little more than including the appropriate recordingsin the dataspace.

12.2 Team

The group managed its changing resources effectively, allocating and re-allocating jobroles as the need arose. Care was taken to ensure that each team member’s skills andenthusiasm were used to the benefit of the project.

12.3 Input Handling

Although strain gauges may provide a clean hardware solution to the detection of damp-ing, there are several promising techniques that may render them unnecessary. Theseinclude digital filtering and direct input transformation using machine learning.

12.4 Performance

The current prototype responds to inputs with no audible latency. Although detailedtesting has not been performed, initial qualitative analysis indicates that the system, asit stands, would meet appropriate latency specifications.

It has not been possible to run the timpani software on a range of architectures andoperating systems. This has made in difficult to justify the choice of platform from aperformance perspective.

Currently thread scheduling is effective, but does not handle resource competition wellenough (i.e. if another program, like X, demands processor resources, the output willclick). Further research into scheduling, especially the real-time variants, should yield asolution to this problem.

Chapter 12 Conclusions 126

12.5 Product Viability

Initial costing and system performance indicate that this project may well evolve into auseful and potentially commercially viable training instrument.

Bibliography

[1] P. Joly A. Chaigne, L. Rhaouti. Time-domain modelling and numerical simulationof a kettledrum. JASA 105(6), 3545-3562, 1999.

[2] V. Doutaut A. Chaigne. Numerical simulations of xylophones. i. time-domain mod-elling of the vibrating bars. JASA 101, 539-557, 1997.

[3] RS Components, electronic component suppliers,http://www.rswww.com.

[4] MicroAccelerometer, Micro-Accelerometers Circuit Cellar INK,http://www.edtn.com/embapps/emba065.htm.

[5] Input pedal sourcehttp://www.yamaha.com/cgi-win/webcgi.exe/DsplyModel/?gEKS00001EP-1.

[6] Edmund Optics, spealise in machine vision optic.http://www.edmundoptics.com/techsupport/DisplayArticle.cfm?articleid=263.

[7] Dr Crowder online robotics course noteshttp://www.soton.ac.uk/ rmc1/robotics/artactile.htm.

[8] Piezoelectric Converters Modeling and Characterization MP Interconsulting websitehttp://mpi.powerultrasonics.com/transducers1.html.

[9] Piezo: Equivalent Circuit on Engineering Fundamentals websitehttp://www.efunda.com/materials/piezo/electronics/elec equiv circuit.cfm.

[10] Piezo-electric transducer detuning by Bertrik Sikken, January 2000http://home.zonnet.nl/bertrik/bat/detuning.htm.

[11] Datasheet: National Semiconductor ADC0801/ADC0802/ADC0803/ADC0804/ADC08058-Bit mP Compatible A/D Converters National Semiconductor Corporation,December 1994 TL/H/5671.

[12] Datasheet: Microchip PIC16F870/871, 28/40-Pin 8-Bit CMOS FLASH Microcon-trollers Microchip Technology Incorporated, 2000 DS30569A.

[13] USB in a NutShell, Making sense of the USB standard by Craig Peacock, December2001http://www.beyondlogic.org/usbnutshell/usb1.htm.

127

BIBLIOGRAPHY 128

[14] An Introduction to USB Development, Jack G. Ganssle,http://www.embedded.com/internet/0003/0003ia2.htm.

[15] Interfacing the Serial/RS-232 Port by Craig Peacock, August 2001http://www.beyondlogic.org/serial/serial1.htm.

[16] High-speed clocking device power supply decoupling Application note AN-43 onnoise from clocking ICs, from IDT (IC manufacturers)http://www.idt.com/docs/App note 43.pdf.

[17] Dr. Howard Johnson, High-speed digital design, On-Line Newsletter, Vol. 2 Issue 8: wire-wraphttp://www.signalintegrity.com/news/2 8.htm.

[18] Nemesys Music, Sample CD: “Ultimate Timpani Library” from Christian and Lakehttp://www.nemesysmusic.com/sounds/index.html.

[19] Specification for the DDrumhttp://www.clavia.se/ddrum/hardware.htm.

[20] Roland V-Drums, electronic drum kitshttp://www.rolandus.com/PRODUCTS/MI/MI.HTM.

[21] Maplin, electronic component suppliers,http://www.maplin.co.uk.

[22] Definition of signal-to-noise ratio Institute for Telecommunication Services,http://www.its.bldrdoc.gov/fs-1037/dir-033/ 4849.htm.

[23] Speed of Sound, Engineering Toolboxhttp://www.engineeringtoolbox.com/Sound/SoundSpeedOfSound.htm.

[24] Maxim 15kV ESD-Protected, +5V RS-232 Transceivers. Maxim Integrated Prod-ucts, May 1996 19-0175; Rev 3.

[25] Datasheet: National Semiconductor LM124/LM224/LM324/LM2902 Low PowerQuad Operational Amplifiers National Semiconductor Corporation, December1994 TL/H/9299.

[26] I. Bork. Measuring the acousitcal properties of mallets. Appl. Aousct. 30,207 - 218,1990.

[27] John Borwick. Microphones Technology and Technique. London : Focal Press., 1990.

[28] James Angus David M. Howard. Acoustics and Psychoacoustics, Music Series Tech-nolog. Focal Press, 1999.

[29] R. E. Davis. Mathamatical Modelling of the Orchestral Timpani. PhD thesis, PhysicsDepartment, Purdue University, 1998.

[30] R. W Ferrier, N.J. Brockett. Reconstructing the shape of a deformable membraneusing image data. International Journal of Robotics Research, Vol. 19, No. 9,pp.795-816, 2000.

BIBLIOGRAPHY 129

[31] MicroAccelerometers Computer Applications Journal.Micro-Accelerometers CircuitCellar INKhttp://www.edtn.com/embapps/emba065.htm.

[32] S R. Gunn. Support vector machines for classification and regression. Technicalreport, ISIS Group, University of Southampton, 1997.

[33] Steve R. Gunn. An electronic timpani. Department of Electronics and ComputerScience, University of Southampton, 2001.

[34] Donald E. Hall. Musical Acoustics Second Edition. Brooks/Cole Publishing Com-pany, 1990.

[35] Horowitz & Hill. The Art of Electronics, Chapter 4 “Basic op-amp circuits”pp179.Cambridge University Press, 1990.

[36] Mark A Yoder J H. McClellan, Ronald W.Schafer. DSP First, A Multimedia Ap-proach. Prentice Hall, Upper Saddle River, NJ 07458, 1999.

[37] Bruel & Kjær. Condenser Microphones and Microphone Amplifiers : Theory andApplication Handbook. Bruel & Kjær, 1997.

[38] R G. Lyons. Understanding Digital Signal Processing. Prentice Hall, 1997.

[39] Karlheinz Brandenburg. Mark Kahrs. Applications of Digital Signal Processing toAudio and Acoustics.(Kluwer international series in engineering and computerscience ; SECS437). Boston London : Kluwer Academic, 1998.

[40] Thomas D. Rossing. Neville H. Fletcher. The Physics of Musical Instruments.Springer-Verlag New York Inc., 1991.

[41] S. J. Orfanidis. Introduction to signal processing. Prentice Hall, 1996.

[42] T. D. Rossing. The physics of kettledrums. Sci. Am. 247, 172-178, 1982.

[43] Advanced Linux Sound Architecture home pagehttp://www.alsa-project.org/.

[44] Analogue Realtime Synthesizer (aRts)http://www.arts-project.org/index.html.

[45] Microsoft’s Direct X home pagehttp://www.microsoft.com/windows/directx/default.asp.

[46] OSS Sound Program Reference Materialhttp://opensound.com/pguide/.

[47] Donald L. Sullivan. Accurate frequency tracking of timpani spectral lines. JASA101, 530 -538, 1997.

[48] M R Sweet. Serial programming guide for posix operating systems. 5th edition, 2ndrevisionhttp://www.easysw.com/ mike/serial”.

Glossary

Terms

Recording Recording of the sound created following a single strike of the timpani, i.e.there is a recording of a strike for each ‘frequency’, ‘position’ and ‘hit strength’

Datapoint A datapoint is the information stored at the instance of sampling a record-ing, i.e. a recording is made up of a sequence of datapoints created at the samplingfrequency. (This is usually referred to as a recording, but to avoid ambiguity thisterm has not been used in the report)

ddrum Clavia’s electronic drum pads, with the ability to detect position and pressure

Matlab “Matrix Laboratory”, versatile mathematical development and modelling soft-ware

Glissando Effect produced by the movement of the pedal while a note is playing,changing the frequency of the sound

Damping Attenuation of the sound with the use of a hand placed gently on the timpaniskin

Abbreviations

ADC Analogue-to-Digital Converter

API Application Programming Interface

B&K Bruel & Kjær, manufacturers of precision audio equipment

DAT Digital Audio Tape

dB Decibel

DOS Disk Operating System

DSP Digital Signal Processing

130

Chapter 12 Glossary 131

FFT Fast Fourier Transform

FPGA Field Programmable Gate Array

IC Integrated Circuit

ISVR Institute of Sound and Vibration Research

OSS Open Source Sound

PC Personal Computer

PCB Printed Circuit Board

PCI Peripheral Component Interface card

PIC Peripheral Interface Controller

PSD Power Spectral Density

PSU Power Supply Unit

RMS Root Mean Square

SLM Sound Level Meter

SNR Signal to Noise Ratio

SPL Sound Pressure Level

Appendix A

Investigation of Clavia Ddrums

Clavia’s ‘ddrums’ and Roland’s ‘V-Drums’ have a reputation for being among the bestelectronic drum pads available at present. Both are capable of detecting position as wellas strength of hit, and also have the ability to detect pressure applied to the head formuting and pitch bending. However neither is available in sizes even close to that of atimpani head, and neither is capable of glissando. Specifications can be found at ((19))and ((20)).

Clearly it would not be possible to find out precisely how the pads worked, as man-ufacturers prefer to keep designs out of competitors’ reach. The opportunity arose todirectly investigate the ddrum pads. Experiments would be limited, as there was notscope in the budget to purchase the pads, and therefore had to be made at a retailer,with their permission. This would also mean that deconstruction the pad to documentthe internal workings could only be done to the extent that no damage would be madeto them.

Results

The pad has a cast aluminium shell with a pliable plastic membrane, which is formedat the edges, making it more rigid at its edge than in its centre. This is then tightenedover a layer of fairly dense foam. It is held together by a set of tensioning screws arounda top ring. The shop assistant told us that in his older model an upper layer of foamhad a cut out in the middle, so that there was a hollow in the centre of the pad. It wasnot possible to remove the foam to confirm the type of sensor used underneath for fearof damaging the device.

The output of the pad had only two terminals so the pads had to use a fairly simplesensor arrangement; the use of multiple devices or electronics within the pad wouldrequire at least three terminals (+volts, ground, and signal). This tended to indicate

1

Appendix A Investigation of Clavia Ddrums 2

the use of a single piezoelectric sensor. An oscilloscope was used to first monitor thedirect output of the pad for given hits.

As shown in figure A.2 the output showed distinctly different waveforms for both centrehits and edge hits, the former being smoother and having little ringing. The edge hitsseem to have a little less decay and a sharper initial pulse. It would appear that thedifferences in the vibrations picked up by the sensors are formed by the way in which thedrum membrane is formed and tensioned. It detected the onset and offset of dampingby a smooth pulse but could not detect a continuous DC offset, again confirming thatit probably uses piezoelectric sensors and nothing else.

The ddrums strength is in its electronics and firmware, with interpretation of the nui-sances in the output of the pad and mapping them to the way the drum is being played.Position, hit strength and damping appear to be determined using only a single piezo-electric sensor.

Appendix A Investigation of Clavia Ddrums 3

Figure A.1: A Clavia Ddrum Pad

Figure A.2: Output from Ddrum Pad

Appendix B

Table of Authorship

This section outlines which team member was primarily responsible for each section ofthe report. This division roughly reflects which parts of the project each team memberfocused on, however it should be noted the team worked in a flexible manner, with eachmember supporting the others’ work.

• Introduction 1: SME

• Research into the Sound of Timpani 2: CJH

• Initial Development 3: RMS

• Specification 4: REW, SME

• Hardware 5: REW

– except sensor selection, written by all, compiled by RMS

• Software Archecture 6

• Input Processing 7: SME

• Sound Generations 8: CJH

– except data driven 8.4: RMS

– and implementation 8.8: RMS

• Concise Hardware 9.1: REW

• Concise Software 9.2: RMS

4

Appendix B Table of Authorship 5

• Concise Input Processing 9.3: SME

• Concise Sound Generation 9.5: CJH

• Concise Dataspace Creation 9.4: CJH

• Project Management 10: REW and RMS

• Recommendations and Conclusions 11: whole team

• Ddrum Research A: CJH

Appendix C

Time Planning

Figure C.1 shows the initial project time plan. Some changes where made towards theend of the project, especially with regard to report writing because the development ofthe prototype took longer than expected as it was delayed by Multidisciplinary Projectsand Semester One exams.

Figure C.1: Project Time Plan Gantt Chart

6

Appendix D

Software Listings

D.1 timpani.h

#ifndef _timpani_h_defined

#define _timpani_h_defined

/********************************************************

* Timpani Group Design Project *

********************************************************

* file: /usr/local/timpani/include/timpani.h *

* *

* This is the general header file that is included *

* by all c files. It defines the shared global data- *

* structures and also the minmal functions that should *

* be provided by each module. It is possible for each *

* part of the program to declare its own header files *

* (espically the sound generation modules) but these *

* are not refered to here as the rest of the code need *

* not (and should not) know about them *

*******************************************************/

/* include all the standard headers (plus a few extra) */

#include <sys/types.h>

#include <sys/stat.h>

#include <sys/soundcard.h>

#include <sys/ioctl.h>

#include <sys/select.h>

#include <sys/time.h>

#include <sys/mman.h>

#include <pthread.h>

#include <unistd.h>

#include <termios.h>

#include <fcntl.h>

#include <errno.h>

#include <stdlib.h>

#include <stdio.h>

#include <math.h>

7

Appendix D Software Listings 8

#include <signal.h>

#include <string.h>

/* Useful #def that make code easier to read */

#ifndef BOOL

#define BOOL

typedef enum

FALSE=0,TRUE=1

bool;

#endif

/* This flag, if commented out, will disable debug output */

#define VERBOSE

/***********************************************************

* Sound Card Configuration *

* This struct is used to store the information required *

* to configure the sound card correctly. *

***********************************************************/

typedef struct SoundCardConfigurationStruct

int setting; /* Used to configure how much memory */

/* the card uses as buffer */

int channels; /* 0=mono (chosen) 1=stero */

int format; /* AFMT_S16_LE; audio format, 2 byte */

/* signed little endian */

int rate; /* sample rate = 44100 Hz */

SoundConfiguration;

/***********************************************************

* Serial Port Configuration *

* This structs hold the information required to initialise *

* and terminate the serial port handling and also to *

* to convert the incoming bit stream into a series of *

* InputFrames.

***********************************************************/

typedef struct SerialPortConfigurationStruct

struct termios oldoptions; /*Serialport configuration */

/*struct used for backing up */

/*old settings */

int handle; /*The descriptor to the port */

int state; /*state variable used for */

/*interpreting input bytes */

int lastPedal; /*Used to store pedal value */

/*in between sets of piezos */

SerialPortConfiguration;

/***********************************************************

* Continuous Input Table *

* Table to store processesed information that reflects the *

* way the timpani changes from sample to sample. Currently *

* only two variables are stored;pedal position and damping.*

* Damping is reasonably difficult to calcuate, effectively *

* requiring a low pass filter. All data stored as floats *

* normailised between 0->1 *


***********************************************************/

typedef struct ContinuousInputStruct

float pedal;

float damping;

ContinuousInput;

typedef struct ContinuousInputTableStruct

int length; /* how long is that table */

int looped; /* =0 until buffer has been filled */

/* for first time, then 1 */

volatile int last; /* most recent reading information */

int bytes; /* how much space does it require */

struct ContinuousInputStruct * table;

struct ContinuousInputStruct current; /*for easy access*/

ContinuousInputTable;

/***********************************************************

* Strike Table *

* Strike table stores processed information that relates *

* to independent strikes of a timpani skin. This currently *

* includes radial distance, strength and pedal at time of *

* strike. A later modification may extend this to include *

* a number which represents which timpani has been hit, *

* although this does have implications as to how the *

* filters work. Again normalised 0->1 *

***********************************************************/

typedef struct StrikeStruct

float strength;

float pedal;

float radial;

Strike;

typedef struct StrikeTableStruct

int length; /* how many strike can be stored */

int looped; /* =0 until buffer has been */

/* filled for first time, the 1 */

volatile int last; /* most recent strike information */


struct StrikeStruct *table;

StrikeTable;

/***********************************************************

* Input Frame Struct *

* This struct is used to communicate between the serial *

* port and the input processing. The pedal and reading *

* values are stored by serial port and the rest is *

* calculated by inputprocessing *

***********************************************************/

typedef struct InputFrameStruct

int pedal; /* Pedal position for this frame */

int reading[3]; /* Direct sensor readings */

float smooth[3]; /* Smooth via average with past */

float mean; /* mean of smoothed readings */

InputFrame;


/***********************************************************

* Input Processing Configuration Struct *

* This contains all the global variables required to *

* distinghish between a hit and damp given a series of *

* InputFrames *

***********************************************************/

typedef struct InputProcessingStruct

int risetime; /*The rising time of the signal */

/*when signal > noise threshold */

int negative_falltime;/*The falltime of the signal */

/*when signal < -noise threshold */

int damptime; /*The duration of the damping */

bool wait_for_zero; /*If true, need to measure the */

/*whole pulse duration, not just */

/*rise time */

int wait_after_hit; /*Decrementing counter used to */

/*ignore readings after a strike */

bool dampingMode; /*TRUE if damp is in progress, */

/*FALSE otherwise */

volatile int index; /*Current index in storage buffers*/

int middle; /*Index of the middle value in buffer*/

int length; /*Length of buffers*/

int bytes; /*Space required for storage */

float zero_point; /*Quantisation level corresponding*/

/*to ground */

float max_noise; /*Noise threshold detected during*/

/*initialisation procedure */

float max_damp; /*Maximum damp value in current damp*/

struct StrikeStruct stored_strike; /*Used to store peak */

/*information when delay is needed*/

InputFrame *table; /*Table of buffers for storing signal*/

InputProcessing;

/**********************************************************

* Waves Table Struct *

* This contain the output from the mod_generate which *

* creates complete samples of timpani strikes based on *

* information contained in the StrikeTable struct. *

* This struct appears overly complex, but it may form part*

* of an interface between two non-synchronisied threads *

* so the information required for reading and writing to *

* it are separted, so that each side has a set that it is *

* responsible for maintaining such that the overside can *

* observe its activity *

**********************************************************/

/* This enum is used to indicate the reading and writing *

* state of the channels in the WaveTable */

typedef enum NOT_ACTIVE,/* The channel is not in use */

IN_PROG, /* is currently reading or writing */

COMPLETE /* finished reading or writing, */

/* but not released */

BufStatus;


typedef struct WaveStruct

/* Flag set by mod_generate, */

/* cleared by mod_channel filter */

volatile bool killRequest;

/* Variables write to by mod_generate */

volatile BufStatus writeStatus;

volatile int writeIndex; /* index of write point */

short *data; /* wave data itself */

/*Variables writen to by mod_channel_filter */

volatile BufStatus readStatus;

volatile int readIndex;

Wave;

typedef struct WaveTableStruct

int length;

int count;

float seconds;

volatile int last;

struct WaveStruct *table;

WaveTable;

/***********************************************************

* Channel Buffer Struct *

* This where the output from the mod_channel filter it *

* placed. It is basically a collection of buffers, the same*

* length as SoundOutputBuffer. Once they have been writen *

* to, they are combined to form the output before it is *

* to mod_post_filer. *

***********************************************************/

typedef struct ChannelBufferStruct

int length; /* How long is the buffer */

int channels; /* How many buffer are there */

int bytes; /* Total amount of memory used */

short *buffer; /* memory block */

unsigned int *chanLen; /* Channel buffers are not */

/* filled to the end, this is a table which indicates */

/* the index of the last meaningful value in each */

/* channels buffer. */

ChannelBuffer;

/***********************************************************

* Sound Output Buffer *

* This buffer contains a sample that will be written to *

* the sound card. *

***********************************************************/

typedef struct SoundOutputBufferStruct

int length; /* how long is the sample */


short *buffer;

SoundOutputBuffer;


/***********************************************************

* DataSpace Struct *

* combines the above structs to create a global variable *

* collection. This is available to all the ’modules’ i.e. *

* mod_generate, mod_channel_filter and mod_post_filter. It *

* does not, however, contain the internal data required by *

* the models, as that is interanl to them and not *

* constrained by main program *

***********************************************************/

typedef struct DataSpaceStruct

/* LOCAL VARIABLES */

/* These variables are mirrored in most */

/* sub-tructs, but since it is so important */

/* this one was added as the definitive article */

/* The number of simulatenous notes ringing on a single */

/* timpani. should be quite a low number */

unsigned int channels;

/* Output buffer size as a power of 2 (has to be 2^n */

/* to be compatible with soundcard initialisation) */

unsigned int outputTwoPower;

/* Variable set to equal the value of outputPower */

unsigned int outputLength;

/*INTERNAL STORAGE STRUCTS*/

struct StrikeTableStruct st;

struct ContinuousInputTableStruct cit;

struct WaveTableStruct wt;

struct ChannelBufferStruct cb;

struct SoundOutputBufferStruct sob;

/*HARDWARE CONFIGURATION STRUCTS*/

struct SoundCardConfigurationStruct sc;

struct SerialPortConfigurationStruct sp;

struct InputProcessingStruct ip;

DataSpace;

/*------------- Funciton Definitions ---------------------*/

/*--------------------------------------------------------**

**--[ SOUND GENERATION MODULE FUNCTIONS ]-----------------**

**--------------------------------------------------------*/

/* -< SAMPLE GENERATION >-------------------------------- */

void init_generate();

void term_generate();

void update_generate();


/* -< CHANNEL FILTER >----------------------------------- */

void init_channel_filter();

void term_channel_filter();

void update_channel_filter();

/* -< POST FILTER >-------------------------------------- */

void init_post_filter();

void term_post_filter();

void update_post_filter();

/*--------------------------------------------------------**

**--[ HARDWARE IO FUNCIONS ]------------------------------**

**--------------------------------------------------------*/

/* -<SOUND CARD FUNCTIONS>------------------------------- */

int init_sound_card();

void term_sound_card();

void exit_proc();

void update_sound_card();

/* -<SERIAL PORT FUNCTIONS >------------------------------*/

int init_serial_port();

void term_serial_port();

void update_serial_port();

/* -<INPUT PROCESSING FUNCTIONS >-------------------------*/

void init_input_processing();

void term_input_processing();

int update_input_processing(); /*return ignored*/

void save_input_frame(InputProcessing *ip,

InputFrame *f);

/*--------------------------------------------------------**

**--[ TABLE MANAGEMENT FUNCTIONS ]------------------------**

**--------------------------------------------------------*/

/* -< STRIKE TABLE >------------------------------------- */

void init_strike_table();

void term_strike_table();

void save_strike(StrikeTable *st,

const Strike *input);

/* -< CONTINUOUS INPUT TABLE FUNCTIONS >----------------- */

void init_continuous_input_table(int size);

void term_continuous_input_table();

void save_continuous_input(ContinuousInputTable *cit,

const ContinuousInput *input);

/* -< WAVE TABLE >--------------------------------------- */

void init_wave_table( float seconds);

void term_wave_table();

/* -< CHANNEL BUFFER >----------------------------------- */

void init_channel_buffer();

void term_channel_buffer();

void combine_channels();

/* -< SOUND OUTPUT BUFFER >------------------------------ */

void init_sound_output_buffer();


void term_sound_output_buffer();

/* This is the single global instance of the DataSpace struct *

* and is held in the main file. */

extern DataSpace ds;

#endif

Listing D.1: Timpani Header file


D.2 PIC program(timp8.c)

This program is compiled and programmed into the PIC. Readings from the externalADCs, and the internal PIC ADC, are formatted and transmitted over the RS232 in-terface to the PC.

/**************************************************************/

/* */

/* File name: TIMP8.C */

/* Description: PIC code for electronic timpani */

/* Inputs: 3 sets of 8-bit data (from 3 ADCs) */

/* 1 analogue input voltage to internal ADC */

/* Outputs: Inputs in prescribed protocol, over RS232 */

/* Version history: */

/* ADPICC1.c Initial code for RS232 data transmission */

/* ADPICC2.c Higher RS232 data rate implemented */

/* ADPICC3.c Pedal input added */

/* ADPICC4.c Byte splitting added */

/* TIMP5.c Byte splitting not required, */

/* external ADCs used */

/* TIMP6.c Triggered mode (third mode) added */

/* TIMP7.c Continuous non-strain gauge mode */

/* (fourth mode) added */

/* TIMP8.c Final protocol agreed upon */

/* (SB A B C pedal A B C), all else excluded */

/* */

/**************************************************************/

#include <16f871.h>

/* set ADC to 8-bit */

#device ADC=8

/* pic configuration flags */

#fuses HS, NOWDT, NOPUT, PROTECT, NOBROWNOUT, NOLVP, CPD, NOWRT, NODEBUG

/* Use a 12MHz Clock */

#use delay (clock=12000000)

/* Configure RS232 */

#use rs232(baud=115200, xmit=PIN_e0, rcv=PIN_e1, parity = n, bits = 8)

main()

int value_piezoa;

int value_piezob;

int value_piezoc;

int value_pedal;

int i;

/* set up A/D converter */

setup_adc(ADC_CLOCK_INTERNAL);

/* use analogue inputs zero only; ref voltage is Vdd */

setup_adc_ports(RA0_ANALOG);

/* initialise adc input to zero */


set_adc_channel(0);

/* turn on green power-on LED */

output_high(pin_e2);

/* hold ADC control pins to ground */

output_low(pin_A1);

output_low(pin_A2);

output_low(pin_A3);

delay_ms(100);

/* start ADCs by releasing control pins */

output_float(pin_A1);



/* This while loop forever */

while (1)

value_pedal = read_adc();

/* Trim Pedal Value, to avoid erroneous start byte*/

if (value_pedal == 255)

value_pedal = 254;

for (i=0; i<=1; ++i)

/* send start byte over RS232 if first part of frame */

if (i==0)

putc(255);

/* send pedal value over RS232 if second part of frame */

if (i==1)

putc(value_pedal);

/* read piezo ADC inputs */

value_piezoa = input_b();

value_piezob = input_c();

value_piezoc = input_d();

/* trim value if greater than 255 */

/*(avoids misinterpretation as start byte)*/

if (value_piezoa == 255)

value_piezoa = 254;

/* send piezo value over RS232 */

putc(value_piezoa);

if (value_piezob == 255)

value_piezob = 254;


putc(value_piezob);

if (value_piezoc == 255)

value_piezoc = 254;

putc(value_piezoc);

Listing D.2: PIC Program Listing


D.3 Matlab Prototype Sound Generation Modelling

disp(’All inputs normalised 0:1’);

disp(’----------------------------’);

ped = input(’Enter pedal position: ’);

hit = input(’Enter hit strength: ’);

pos = input(’Enter distance from center: ’);

damp = input(’Enter damping level: ’);

%------------------------------------------------------

% Pre Program, loads dataspace specs from dataspace.mat

% and constructs mapping

%load database

%filetoload = [’D:\dataspace\dataspace.mat’];

%load(filetoload);

% Normalise Freq

df = [82 113 132 141 154]; %Hz

Lf = length(df);

a = 0;

for a = 1:Lf

nf(a) = (df(a)-df(1))/(df(Lf)-df(1));

end

sf = (df(1)/df(Lf));

rf = 1-sf;

% Normalise Hit strength

Ls = 5;

b = 1/Ls;

c = -b/2;

for a = 1:Ls

ns(a) = c + (b*a);

end

% Normalise Position

Lp = 8;

b = 1/(Lp-1);

np(1)=0;

for a = 1:(Lp-1)

np(a+1) = b*a;

end

% Damping

damp = damp * 6;

% Other dataspace info

Fs = 44100;

%------------------------------------------------------

% Main Program

% Find closest freq in dataspace and shift needed

b=1;

for a = 1:Lf


diff = abs(ped-nf(a));

if diff < b

nearf = a;

end

b = diff;

end

a = sf + (nf(nearf)*rf);

b = sf + (ped*rf);

shift = b/a;

% Find closest strength in dataspace and shift needed

b=1;

for a = 1:Ls

diff = abs(hit-ns(a));

if diff < b

nears = a;

end

b = diff;

end

amp = hit / ns(nears);

% Find closest position in dataspace

b=1;

for a = 1:Lp

diff = abs(pos-np(a));

if diff < b

nearp = a;

end

b = diff;

end

% look up sample in data space

f=nearf;

s=nears;

p=nearp;

disp(’----------------------------’);

fprintf(’Using sample f%0.0fs%0.0fp%0.0f.mat\n’,f,s,p); % only to let me know its working!

smple = (f-1)*Ls*Lp + (s-1)*Lp + p;

lngth = index(smple,1);

start = index(smple,2);

finish = index(smple,3);

wavedata = dataspace(start:finish);

wavedata = double(wavedata); % matlab will only work with doubles!

% returns wavedata

% Frequency: Interpolate and resample

b=0;

newdata = zeros(1,floor(lngth/shift)-1);

for a = 1:shift:(lngth-0.0001) %ie upto but not including length(wavedata)

b = b + 1;

s1 = floor(a);

newdata(b) = (a-s1)*(wavedata(s1+1)-wavedata(s1)) + wavedata(s1);

end

% Hit Strength: adjust amplitude

newdata=newdata*amp;

damp = 1 - (damp * 0.0001); % this would not be in this section

dampvalue = damp; % damp called dampvalue


damprate = 1;

if damp > 0.1 %arbitary noise value chosen

for a = 1:lngth

damprate = damprate * damp;

dampdata(a)= newdata(a)*damprate;

end

end

%------------------------------------------------------

%play sample

playdata=newdata/32768;

sound(playdata,44100);

Listing D.3: Matlab Prototype Sound Generation Modelling

Appendix E

Hardware Circuit Diagram

21

Appendix E Hardware Circuit Diagram 22

1M

2.2k

1k LM324

(1)

ADC0804

11

12

13

14

15

16

17

20

4

9

19

6

18 3

5

7 8

1 2 10

10k

10k

10k

+5V(A)

+5V(D)

+2.5V ref

CLK

ADC0804

11

12

13

14

15

16

17

20

4

9

19

6

18 3

5

7 8

1 2 10

ADC0804

11

12

13

14

15

16

17

20

4

9

19

6

18 3

5

7 8

1 2 10

CLK

+2.5V ref

+5V(D)

CLK

+2.5V ref

+5V(D)

CLK

+2.5V ref

+5V(A)

2.2k

1k LM324

(2)

+5V(A)

2.2k

1k LM324

(3)

+5V(A)

PIC16F871

PIC control to ADCs at power-up

Analogue-to- digital

converters (ADCs)

+2.5V ADC reference

voltage divider

ADC clocking RC network

Sensor adjustment

potentiometers

LM324 buffer op-amps

PIC microcontroller

33

34

35

36

37

38

39

40

15

16

17

18

23

24

25

26

19

20

21

22

27

28

29

30

8

9

10

3

4

5

11

32

1

1k

MAX232

+5V(D)

1k

6

7 12 31

1k 1k Green LED power indicator

RS-232 level shifter 1uF

1uF

1

3

4

5

10

9

11

12

8

14

13

7

6

2

16 +5V(D)

1uF 1uF

1uF

+5V(D)

15

2

13

14

15pF

15pF

12MHz

Piezoelectric transducer

1M Piezoelectric

transducer

1M Piezoelectric

transducer

+5V(A)

Potentiometer in tuning pedal

100pF

20k

2

3

5

9-pin D-type connector to PC COM1 serial port

2805 2805

+5V(A) +5V(D) Power supply input

6V - 20V DC

+V

0V Analogue ground

Digital supply

regulator

Digital ground

Analogue supply

regulator

Figure E.1: Circuit diagram

Appendix F

Final Budget Breakdown

N.B. PC Components do not include VAT.

23

Appendix F Final Budget Breakdown 24

HardwarePiezoelectric transducers £5.87Adhesives £6.85PIC microcontroller £7.48Prototyping circuit board £2.54Plastic case £3.50Other hardware £40.98Project PC componentsAMD Athlon XP 1600+1.4Ghz SoA (Processor)

£106.00

Gigabyte SoA VIA KT266ATX A (Motherboard)

£75.00

IBM Deskstar 60GXP 20.6GBUDMA100 (Hard disk)

£63.00

Suntek Computers Ltd.Viper ATX Midi Tower 250W(Case)

£42.00

Crucial Technology 256MB184DIMM PC2100 NP CL2.5(Memory x 2)

£52.62

AOpen 52x IDE InternalOEM (CD ROM)

£21.00

Mitsumi 1.44MB Internal 3.5”(Floppy Disk)

£6.50

Dabs Value 105 Key PS/2(Keyboard)

£4.00

Mitsumi 2 Button ClassicPS/2 Retail (Mouse)

£4.00

Extra PSU (350W) (PowerSupply)

£9.40

Extra hard disk and delivery(HD for Linux)‘

£81.03

MiscellaneousLatex guide £35.70Timpani transport insurance £25.00Total £673.22

Appendix G

Initial Idea Sketches

Figure G.1: Separate Pads, but One Main Processor

25

Appendix G Initial Idea Sketches 26

Figure G.2: Intertial Measurement of Mallet Head

Figure G.3: Resitive Foam on Ring-Dot Substrate


Figure G.4: Concentric Rubber Rings, with Individual Pressure Sensor

Figure G.5: Mock Skin with Microphone Array

Figure G.6: Camera Based Viewing


Figure G.7: Rigid Plate Supported on Strain Gauges

Figure G.8: Fluid Bath, With Sensor “Hairs”

Figure G.9: Completely Virtual Solution

Appendix H

Timpani Photographs

29

Appendix H Timpani Photographs 30

Figure H.1: Concert Timpani at the Mayflower Theatre, Southampton

Appendix H Timpani Photographs 31

Figure H.2: Timpani Experiment in the Anechoic Chamber

Appendix I

Software Packages Used

The following is a list of the software packages used during this project. This softwaremay be helpful for any future work on electronic timpani.

Windows software:

CoolEdit 2000 was used to import the recordings of the timpani from the DATrecorder. It is primarily a sound editing package.

Goldwave was also used for sound editing. The interface was found to be easier towork with than CoolEdit.

Matlab was used to perform offline frequency and amplitude shifting of the recordings.

MPLAB served as a complete PIC programming environment. Code can be writtenand compiled, and the PIC can be programmed, with this single package. The CCScompiler plug-in was required to allow the PIC C language to be used. The physicalprogrammer adapter was the PICstart Plus, obtained on loan from ECS Stores.

Listen32 proved invaluable in capturing serial data transmitted by the PIC to the PC.

Linux software:

gcc GNU command line compiler.

gdb GNU command line debug program.

pdflatex was the package for compiling and producing the report. The Latex formatis highly recommended over Microsoft Word, as the documents are more professionallypresented and the individual parts of the document can be simultaneously edited bymultiple users.

32

Appendix J

M-File index

Many of the .m files are specific to a certain stage in the process of indexing the recordingsand converting into a single dataspace. If the files are to be used or edited at a laterstage by a third party it is important to be careful of the names of the .mat files thatthey refer to and the order in which they can be used.

33

Appendix J M-File index 34

checkstr.m Effectively forms a console to quickly view the corrected hit-strength of each recording, listen to the recording, correctthe amplitude if desired and listen to the corrected recording

checkstrfreq.m Similar to above, except can resample and adjust the ampli-tude from a different frequency, instead of simply adjustingthe amplitude of the recording

clipping.m Lists all the recordings that contain clippingcreate.m From a single large array to form the dataspace from, con-

verts to 16 bit integers and index’s the position of the record-ing in the array

damping.m An example of a damping envelope used in model.mfindclipping.m The routine used to find whether the recordings have

clipped. Used in the file indexfindend.m Finds and plots the end of a recordingfindmax.m Find the maximum value from all recordingsfrequency.m Index’s the first 6 mode lines from all the recordingsgain10down.m Reduce the gain of certain recordings by 10dBgain10up.m Increase the gain of certain recording by 10dBhitstrength.m Correcting the position dependence in the level in order to

identify the strikes with spurious levelsloadmat.m Loads a recordingmake16bit.m Normalizes the recordings to a maximum value of ( 32768make44k.m Resample all the recording to a sampling frequency of

44.1Khz from 48Khzmakefileindex.m Makes a complete index of all the recordingsmaxval.m To find the maximum value from all the recordingsmodel.m Matlab version of the modeling codeoffset.m Correct for non-zero ground in the recordings, using the

mean value of the last half-secondopenlots.m Framework code used to work with all of the recordings,

useful base to create new code.opensingle.m Opens a single recording into the working environmentplay.m Play a recordingrootmeansquare.m A function to find the root mean square of an arraysingleindex.m Index a single recording. Shows more parameters than the

complete index and displays a graph of the first 6 mode linestailandcut.m Find the end of all the samples and tail to zero using a linear

envelopetrans.m Form the dataspace in a binary filetrim.m Finds the start of the recording above the noise and saves

the new recording with the correct start

Table J.1: Index of M-Files

Appendix K

CD Contents

35

Appendix K CD Contents 36

/hardware: Directory. Contains Hardware Resourcestimp8.c PIC source code16F871.pdf PIC Microcontroller PIC16F870/871 datasheetmax232.pdf RS-232 Transceiver MAX232 datasheetlm324.pdf Quad Operational Amplifier LM324 datasheetadc0804.pdf Analogue to Digital Converter ADC0804 datasheet/timpani: Directory. Should be copied to /usr/local/timpani/build.sh Script to run the various make files required for complete

rebuildchanges Running log of changesclean.sh Script to clean out all binary filesiptst Test program: Input Processingmakefile Primary make file, uses binaries in /timpani/lib/ to make

executablessetperm.sh Must be run by root, sets permissions for serial port accesssptst Test program: Serial Porttimp Main Timpani Excutabletodo Things left in progress/timpani/data:animals.dat Data space contain various animal soundsdataspace.dat Symbolic link to which ever space is currently in usefarts.dat Immature but entertaining dataspacenumbers.dat Range of numbers from center to edgetimp.dat Dataspace for real timpani soundsworms.dat Amusing dataspace based on popular video game/timpani/general: Directory. Contain data storage and hardware interface codedataspace.c StrikeTable, ContinousInputTable, WaveTable, Channel-

Buffer, OutputBufferinputprocessing.c input processes moduleip test main.c short main file used by iptst programmain.c main file used by timp programmakefile create binaries and copies them to /timpani/lib/serialport.c all code required to handled serial portsoundcard.c code that handles the sound cardsp test main.c main file used for the sptst program/timpani/include: primary include directorytimpani.h Included by all files, gives access to global dataspace/timpani/lib: Where binaries are stored before linking/timpani/lib/mods: Directory. Contains all code for sound generationmakefile generates binaries and copies them to /timpani/lib/mod channel filter.c Handles reading from WaveTable and writing to Channel-

Buffermod channel filter.h Header file for abovemod generate.c Handles reading Strike and ContinuousInputTable and writ-

ing to WaveTablemod.h Holds the recordings table used by mod generatemod post filter.c Currently not usedmod post filter.h Header file for above

Table K.1: List of Files to Found on CD

Appendix L

Recording Index

Complete listing of the recordings used when constructing the dataspace. These can befound on the project CD in ‘.mat’ format. The headings are as follows:

f Frequency (out of 5)s Hit Strength (out of 5)p Position (out of 8)t Take (take 1 or 2)size The number of datapoints in the sample (after trimming and

tailing)freq The fundamental frequency of the recording in Hz, i.e. the

pitch of the note perceived+n The maximum datapoint value in the last 0.5 seconds of

data-n The minimum datapoint value in the last 0.5 seconds of datamean The mean of the mean of the last 0.5 seconds of datarms The RMS value of the last 0.5 seconds of datacli Clipping, indicates the first datapoint in the recording at

which clipping occurslim Limiting, indicates the first datapoint in the recording that

reaches within 95% of the maximum possible valuer Review?, if the recording indicates limiting value but not

clipping a value of 1 indicates that a manual check of thedata should be made

1st100ms The rms value of the first 100ms of data as an indication ofthe hit strength

hit The 1st100ms value is corrected to take account of the posi-tion dependence of the level (8.5.5). The value is normalisedsuch that the maximum value would be 100 before the cor-rection for position is made

37

Appendix L Recording Index 38

f s p t size frq +n -n mean rms cli lim r 1st100ms hit1 1 1 1 237315 82 24 -10 7.51 8.81 0 0 0 1656.36 0.121 1 1 2 202267 82 22 -6 7.38 8.11 0 0 0 1674.69 0.131 1 2 1 352343 82 22 -8 7.41 8.32 0 0 0 1362.22 0.771 1 2 2 308116 82 24 -9 7.62 8.73 0 0 0 1511.43 0.851 1 3 1 399951 82 23 -7 7.46 8.46 0 0 0 1292 1.361 1 3 2 348466 82 24 -9 7.45 8.71 0 0 0 972.27 1.031 1 4 1 453707 82 20 -6 7.49 8.23 0 0 0 856 1.321 1 4 2 393055 82 29 -11 7.4 9.34 0 0 0 746.71 1.151 1 5 1 515225 82 24 -5 7.42 8.22 0 0 0 556.89 1.131 1 5 2 305559 82 30 -23 7.54 10.54 0 0 0 308.78 0.631 1 6 1 397988 82 23 -8 7.3 8.37 0 0 0 172.7 0.441 1 6 2 386429 82 24 -10 7.43 8.65 0 0 0 208.76 0.531 1 7 1 397351 82 25 -8 7.56 8.81 0 0 0 237 0.711 1 7 2 594364 82 22 -8 7.37 8.45 0 0 0 514.55 1.551 1 8 1 325951 82 20 -8 7.67 8.38 0 0 0 200.84 0.71 1 8 2 390427 82 23 -8 7.57 8.64 0 0 0 292.63 1.031 2 1 1 370841 82 23 -9 7.48 8.51 448 440 0 9880.04 3.721 2 1 2 357896 82 22 -7 7.48 8.23 0 0 0 6778.05 2.551 2 2 1 469912 82 22 -6 7.48 8.36 0 0 0 5296.92 3.371 2 2 2 401874 82 26 -10 7.48 8.96 0 0 0 5611.91 3.571 2 3 1 575284 82 20 -6 7.61 8.26 0 0 0 6279.07 5.631 2 3 2 369143 82 44 -26 7.6 13.86 0 0 0 4424.79 3.971 2 4 1 608097 82 22 -10 7.44 8.29 0 0 0 4290.97 4.971 2 4 2 586010 82 25 -9 7.5 8.74 0 0 0 2911.69 3.371 2 5 1 501591 82 27 -13 7.45 9.1 0 0 0 4640.09 6.581 2 5 2 525318 82 30 -11 7.45 9.35 0 0 0 2602.01 3.691 2 6 1 611465 82 26 -8 7.6 8.7 0 0 0 1705.53 2.861 2 6 2 501778 82 31 -15 7.45 10.15 0 0 0 2454.91 4.121 2 7 1 690566 82 22 -4 7.62 8.3 0 0 0 2655.54 5.151 2 7 2 573045 82 23 -8 7.38 8.48 0 0 0 1561.77 3.031 2 8 1 411153 82 21 -5 7.51 8.24 0 0 0 719.43 1.581 2 8 2 591637 82 23 -6 7.49 8.4 0 0 0 2106.55 4.631 3 1 1 440157 82 21 -4 7.38 8.05 248 246 0 15649.56 5.311 3 1 2 364634 82 27 -13 7.8 9.64 299 291 0 12773.45 4.341 3 2 1 516393 82 21 -5 7.5 8.33 306 299 0 12839.52 7.821 3 2 2 495483 82 22 -8 7.36 8.37 411 405 0 12316.61 7.51 3 3 1 563496 82 26 -12 7.55 9.07 655 649 0 9855.83 8.661 3 3 2 570896 82 24 -11 7.64 8.78 0 0 0 8333.6 7.321 3 4 1 465490 82 33 -16 7.67 10.1 0 0 0 7429.39 8.521 3 4 2 506393 82 26 -10 7.46 9.16 0 0 0 6352.61 7.291 3 5 1 576029 82 29 -14 7.74 9.83 0 0 0 5828.81 8.261 3 5 2 611896 82 19 -6 7.65 8.28 0 0 0 4627.28 6.561 3 6 1 974645 82 25 -8 7.36 8.29 0 0 0 4667.16 7.871 3 6 2 619361 82 22 -6 7.69 8.35 0 0 0 3989.59 6.731 3 7 1 813418 82 20 -6 7.38 8.17 0 0 0 3498.2 6.841 3 7 2 687737 82 21 -4 7.57 8.21 0 0 0 3299.15 6.451 3 8 1 462080 82 47 -23 7.4 12.4 0 0 0 2842.27 6.321 3 8 2 585820 82 21 -7 7.73 8.37 0 0 0 1513.7 3.37


f s p t size frq +n -n mean rms cli lim r 1st100ms hit1 4 1 1 479482 82 27 -10 7.39 8.56 211 208 0 19840.74 10.261 4 1 2 444920 82 20 -5 7.55 8.2 251 249 0 15215.52 7.871 4 2 1 559360 82 20 -4 7.57 8.17 218 216 0 17649.6 12.151 4 2 2 543695 82 22 -6 7.41 8.15 225 223 0 16844.86 11.61 4 3 1 536126 82 20 -5 7.77 8.42 615 243 0 13749.56 11.831 4 3 2 558500 82 20 -7 7.36 8.1 614 463 0 12898.33 11.11 4 4 1 562988 82 20 -7 7.57 8.23 616 611 0 10723.58 11.071 4 4 2 580063 82 21 -8 7.47 8.16 0 0 0 10322.84 10.651 4 5 1 629391 82 24 -11 7.35 8.65 0 0 0 9845.37 11.851 4 5 2 748416 82 20 -5 7.53 8.22 0 0 0 7772.95 9.351 4 6 1 799565 82 19 -5 7.6 8.19 0 0 0 9078.67 12.481 4 6 2 707335 82 22 -7 7.43 8.15 0 0 0 6409.42 8.811 4 7 1 622887 82 19 -4 7.62 8.2 0 0 0 8384.37 12.971 4 7 2 715714 82 20 -5 7.6 8.29 0 0 0 5822.09 9.011 4 8 1 656353 82 21 -7 7.61 8.29 0 0 0 2846.67 4.891 4 8 2 460400 82 42 -29 7.41 15.01 0 0 0 4242.6 7.291 5 1 1 536990 78 51 -6 22.37 24.15 182 40 0 41788.83 21.071 5 2 1 991075 78 41 3 22.44 22.95 202 47 0 34709.37 24.091 5 3 1 789107 78 44 6 25.07 25.49 567 49 0 31328.14 27.691 5 4 1 781646 78 38 3 21.44 21.95 191 56 0 22727.17 24.41 5 5 1 732648 78 47 3 25.44 26.03 0 126 1 13457.59 171 5 6 1 632486 78 44 3 24.99 25.56 0 44 1 21809.7 31.691 5 7 1 675370 78 41 3 21.65 22.16 0 50 1 13387.95 21.991 5 8 1 507398 78 51 -6 23.08 24.23 0 0 0 6389.72 11.712 1 1 1 54347 113 21 -7 7.65 8.36 0 0 0 296.73 0.112 1 2 1 88636 113 22 -6 7.59 8.31 0 0 0 382.39 0.242 1 3 1 94501 113 21 -6 7.43 8.17 0 0 0 159.02 0.142 2 1 1 146710 113 21 -8 7.49 8.25 0 0 0 4028.67 2.422 2 2 1 184359 113 22 -6 7.48 8.23 0 0 0 2560.88 1.982 2 3 1 280585 113 20 -5 7.42 8.12 0 0 0 1371.47 1.32 2 4 1 313544 113 22 -6 7.54 8.26 0 0 0 1320.15 1.482 2 5 1 368253 113 21 -11 7.55 8.32 0 0 0 1302.75 1.682 2 6 1 378251 113 21 -6 7.61 8.33 0 0 0 973.64 1.432 2 7 1 385958 113 22 -6 7.52 8.32 0 0 0 1289.2 2.112 2 8 1 206312 113 33 -23 7.38 11.46 0 0 0 427.31 0.772 3 1 1 156046 113 25 -9 7.53 8.78 0 0 0 5861.21 2.612 3 1 2 211437 113 22 -6 7.58 8.44 219 216 0 12353.93 5.52 3 2 1 289245 113 25 -13 7.4 8.82 0 396 1 7760.25 5.512 3 2 2 371380 113 20 -7 7.37 8.09 209 206 0 12055.97 8.562 3 3 1 434639 113 23 -8 7.75 8.75 0 0 0 6081.83 5.932 3 3 2 499501 113 20 -4 7.4 8.09 397 207 0 10087.61 9.832 3 4 1 408271 113 21 -7 7.82 8.69 0 0 0 3473.03 4.32 3 4 2 472772 113 22 -5 7.46 8.22 0 0 0 6974.14 8.642 3 5 1 465920 113 22 -6 7.64 8.34 0 0 0 2375.03 3.572 3 5 2 488589 113 21 -7 7.49 8.41 0 0 0 4961.04 7.462 3 6 1 419950 113 20 -6 7.57 8.42 0 0 0 2033.51 3.592 3 6 2 482175 113 25 -8 7.54 8.5 0 0 0 5339.48 9.442 3 7 1 445088 113 22 -8 7.55 8.35 0 0 0 1858.06 3.782 3 7 2 459941 113 23 -9 7.5 8.78 0 0 0 5303.04 10.782 3 8 1 312565 113 28 -11 7.2 8.5 0 0 0 498.29 1.142 3 8 2 298917 113 33 -19 7.42 10.89 0 0 0 1803.12 4.14


f s p t size frq +n -n mean rms cli lim r 1st100ms hit2 4 1 1 268729 113 44 3 24.57 25.06 196 57 0 31550.71 18.812 4 2 1 127483 113 389 -152 22.1 41.92 167 31 0 35831.49 42.712 5 1 1 370277 113 76 -22 23.32 26.14 71 30 0 76346.09 62.152 5 2 1 298238 113 89 -19 24.28 27.42 70 29 0 69802.83 59.672 5 3 1 491008 113 73 -28 23.32 26.39 67 27 0 61182.41 54.792 5 4 1 541240 113 66 -22 23.59 26.1 210 113 0 69024.09 64.622 5 5 1 586281 113 66 -19 23.66 26.07 150 63 0 60330.68 58.942 5 6 1 570473 113 168 -32 23.42 26.59 86 18 0 63705.13 64.832 5 7 1 574305 113 76 -22 23.33 26.16 98 22 0 54288.23 57.462 5 8 1 523570 113 76 -35 23.57 27.27 77 21 0 44021.37 48.383 1 1 1 51753 132 22 -8 7.48 8.28 0 0 0 668.22 0.083 1 1 2 48247 132 20 -4 7.57 8.23 0 0 0 958.49 0.123 1 2 1 85816 132 20 -7 7.54 8.38 0 0 0 1188.51 0.693 1 2 2 53918 132 19 -6 7.42 8.09 0 0 0 447.47 0.263 1 3 1 71215 132 22 -6 7.56 8.36 0 0 0 362.57 0.383 1 3 2 59150 132 21 -5 7.4 8.04 0 0 0 277.18 0.293 1 4 1 119715 132 28 -10 7.63 8.41 0 0 0 575.33 0.873 1 4 2 43429 132 22 -6 7.54 8.29 0 0 0 74.37 0.113 1 5 1 104600 132 26 -10 7.34 8.58 0 0 0 497.99 0.983 1 5 2 57157 132 21 -5 7.48 8.15 0 0 0 124.77 0.253 1 6 1 70058 132 26 -8 7.63 8.62 0 0 0 59.81 0.153 1 6 2 58083 132 20 -6 7.34 8 0 0 0 130.14 0.323 1 7 1 88401 132 22 -7 7.52 8.33 0 0 0 126.54 0.373 1 7 2 62735 132 21 -9 7.52 8.3 0 0 0 89.3 0.263 1 8 1 104531 132 22 -7 7.46 8.24 0 0 0 73.13 0.253 1 8 2 98600 132 32 -14 7.54 9.15 0 0 0 151.64 0.513 2 1 1 108289 132 21 -5 7.52 8.17 0 0 0 3932.08 2.683 2 2 1 134956 132 19 -5 7.47 8.1 0 0 0 4397.62 3.463 2 3 1 197507 132 23 -8 7.49 8.42 0 0 0 4877.76 4.343 2 4 1 259929 132 22 -8 7.51 8.4 0 0 0 5583.71 5.563 2 5 1 272573 132 20 -5 7.34 8.04 0 0 0 3648.43 4.013 2 6 1 208449 132 25 -9 7.55 8.87 0 0 0 2328.81 2.813 2 7 1 273439 132 22 -8 7.4 8.27 0 0 0 2704.42 3.543 2 8 1 248547 132 21 -6 7.49 8.2 0 0 0 677.12 0.963 3 1 1 174332 132 25 -6 7.44 8.33 200 196 0 11156.2 5.733 3 2 1 191511 132 22 -9 7.52 8.48 205 201 0 11406.84 7.73 3 3 1 259191 132 25 -9 7.59 8.99 214 202 0 11414.09 9.563 3 4 1 363404 132 26 -7 7.55 8.47 0 0 0 11293.65 11.283 3 5 1 353467 132 21 -6 7.45 8.25 0 0 0 7291.34 8.463 3 6 1 365504 132 22 -6 7.45 8.25 0 0 0 6689.7 8.853 3 7 1 356488 132 22 -6 7.45 8.33 0 0 0 4607.49 6.843 3 8 1 342922 132 23 -15 7.5 8.67 0 0 0 3776.91 6.223 4 1 1 221897 132 47 6 25.05 25.49 497 168 0 22874.91 12.033 4 2 1 232124 132 41 3 22.49 23 557 212 0 25280.49 17.083 4 3 1 322852 132 47 3 25.31 25.9 191 152 0 18418.43 15.213 4 4 1 355489 132 51 3 22.6 23.16 0 149 1 15955.46 15.573 4 5 1 387359 132 41 6 24.51 24.92 0 4905 1 1193.8 1.343 4 6 1 378982 132 47 3 21.82 22.32 0 0 0 10498.54 13.393 4 7 1 383500 132 44 6 24.91 25.45 0 0 0 10548.79 15.043 4 8 1 268142 132 44 3 21.9 22.47 0 0 0 3084.7 4.86


f s p t size frq +n -n mean rms cli lim r 1st100ms hit4 1 1 1 11323 141 24 -8 7.46 8.59 0 0 0 334.54 0.074 1 2 1 34803 141 23 -7 7.69 8.62 0 0 0 175.65 0.14 1 3 1 54068 141 25 -6 7.59 8.61 0 0 0 320.43 0.34 1 4 1 23090 141 27 -13 7.67 9.46 0 0 0 49.73 0.064 1 5 1 54875 141 33 -16 7.62 10.24 0 0 0 221.2 0.364 1 6 1 42694 141 23 -6 7.3 8.36 0 0 0 95.02 0.194 1 7 1 175827 141 26 -8 7.51 8.65 0 0 0 52.77 0.124 1 8 1 99473 141 23 -7 7.54 8.35 0 0 0 89.42 0.244 2 1 1 51757 141 21 -6 7.61 8.47 0 0 0 2788.71 1.064 2 2 1 88777 141 20 -5 7.67 8.39 0 0 0 2220.72 1.324 2 3 1 397719 141 19 -6 7.47 8.13 0 0 0 1810.21 1.464 2 4 1 146702 141 20 -8 7.46 8.22 0 0 0 1386.1 1.414 2 5 1 129713 141 22 -6 7.45 8.27 0 0 0 681.49 0.844 2 6 1 155902 141 21 -7 7.48 8.33 0 0 0 867.92 1.254 2 7 1 207167 141 80 -67 7.53 8.99 0 0 0 780.49 1.294 3 1 1 151886 141 21 -5 7.7 8.39 360 215 0 8985.58 2.84 3 2 1 444671 141 20 -6 7.62 8.25 0 0 0 6136.94 2.784 3 3 1 167642 141 22 -6 7.37 8.19 0 0 0 4795.24 2.854 3 4 1 432470 141 21 -7 7.49 8.26 0 0 0 5137.61 3.784 3 5 1 223109 141 20 -7 7.55 8.28 0 0 0 3270.59 2.874 3 6 1 383596 141 22 -6 7.29 8.2 0 0 0 3403.05 3.474 3 7 1 259514 141 22 -7 7.64 8.52 0 0 0 2332.16 2.714 3 8 1 221313 141 22 -6 7.39 8.12 0 0 0 968.88 1.264 4 1 1 205090 141 44 9 25.1 25.54 170 50 0 32056.3 22.214 4 2 1 264310 141 44 9 25.84 26.25 164 47 0 32512.33 25.434 4 3 1 311377 141 44 3 24.71 25.36 156 47 0 31356.26 27.334 4 4 1 316558 141 38 3 21.64 22.11 0 47 1 27810.7 26.724 4 5 1 314347 141 51 6 25.16 25.75 175 43 0 24362.84 25.594 4 6 1 331989 141 47 3 24.61 25.09 1789 41 0 23596.52 26.894 4 7 1 363157 141 44 3 24.68 25.1 0 44 1 18711.93 22.994 4 8 1 337468 141 44 3 25.3 25.77 0 81 1 11589.51 15.284 5 1 1 416563 141 44 6 25.57 25.99 148 47 0 41140.14 30.574 5 2 1 665897 141 41 3 21.98 22.46 147 38 0 37956.32 30.754 5 3 1 719767 141 41 3 21.74 22.23 142 37 0 40161.49 35.224 5 4 1 336254 141 44 6 25.35 25.75 127 35 0 34952.63 32.994 5 5 1 346126 141 41 0 22.54 23.07 1258 30 0 35108.57 35.484 5 6 1 659522 141 44 3 25.37 25.87 4465 29 0 30545.54 32.914 5 7 1 833750 141 44 6 24.84 25.35 425 21 0 25997.85 29.754 5 7 2 467847 141 47 6 25.93 26.45 2126 37 0 28688.39 32.834 5 8 1 245461 141 66 -6 22.22 22.8 0 0 0 3495.34 4.23


f s p t size frq +n -n mean rms cli lim r 1st100ms hit5 1 1 1 52657 154 20 -5 7.76 8.39 0 0 0 2438.46 0.455 1 1 2 32360 154 20 -5 7.51 8.17 0 0 0 1498.17 0.285 1 2 1 66391 154 20 -7 7.67 8.46 0 0 0 1713.75 1.115 1 2 2 92965 154 20 -6 7.31 7.98 0 0 0 855.5 0.555 1 3 1 97214 154 21 -5 7.53 8.12 0 0 0 2305.17 2.555 1 3 2 65715 154 18 -3 7.5 8.08 0 0 0 634.49 0.75 1 4 1 106479 154 23 -5 7.33 7.97 0 0 0 2068 3.245 1 4 2 60643 154 20 -4 7.52 8.14 0 0 0 394.35 0.625 1 5 1 106474 154 21 -5 7.65 8.28 0 0 0 1632.69 3.315 1 5 2 52913 154 20 -5 7.66 8.34 0 0 0 301.82 0.615 1 6 1 96229 154 22 -7 7.57 8.24 0 0 0 644.61 1.65 1 6 2 36657 154 20 -5 7.55 8.2 0 0 0 128.19 0.325 1 7 1 117757 154 19 -5 7.44 8.05 0 0 0 342.08 1.015 1 7 2 67178 154 21 -5 7.56 8.3 0 0 0 185.09 0.555 1 8 1 109010 154 20 -6 7.46 8.09 0 0 0 184.94 0.635 1 8 2 71591 154 21 -5 7.56 8.22 0 0 0 134.78 0.465 2 1 1 62131 154 23 -7 7.65 8.53 0 0 0 3501.34 0.95 2 1 2 123004 154 19 -5 7.48 8.08 180 177 0 10888.52 2.85 2 2 1 191433 154 20 -7 7.63 8.41 198 191 0 9121.52 4.615 2 2 2 197531 154 21 -7 7.47 8.21 185 182 0 10791.93 5.465 2 3 1 161224 154 23 -8 7.68 8.74 0 0 0 7538.43 5.695 2 3 2 197464 154 24 -6 7.35 8.14 0 199 1 9493.95 7.165 2 4 1 230925 154 23 -10 7.59 8.63 0 0 0 8923.13 8.955 2 4 2 215846 154 25 -7 7.54 8.45 0 0 0 7423.56 7.455 2 5 1 202372 154 21 -8 7.62 8.34 0 0 0 4057.32 5.085 2 5 2 227997 154 20 -8 7.57 8.28 0 0 0 5356.46 6.75 2 6 1 177175 154 22 -7 7.44 8.35 0 0 0 4023.86 6.045 2 6 2 181115 154 35 -17 7.41 9.35 0 0 0 5690.05 8.535 2 7 1 165914 154 21 -10 7.51 8.42 0 0 0 2259.66 3.955 2 7 2 232283 154 24 -10 7.51 8.57 0 0 0 3685.46 6.445 2 8 1 171247 154 22 -7 7.3 8.16 0 0 0 695.65 1.395 2 8 2 190654 154 21 -8 7.45 8.37 0 0 0 1196.71 2.395 3 1 1 134841 154 41 3 22.63 23.17 327 140 0 23224.78 11.815 3 2 1 229064 154 44 6 23.38 23.95 323 143 0 23273.19 15.35 3 3 1 233539 154 41 3 23.58 24.11 0 148 1 15429.82 12.445 3 4 1 246691 154 44 3 23.03 23.71 0 133 1 16418.39 15.695 3 5 1 259280 154 47 3 23.49 24.1 0 135 1 14494.5 16.015 3 6 1 266672 154 44 3 22.88 23.54 0 154 1 13174.45 16.525 3 7 1 276859 154 44 6 23.85 24.36 0 0 0 8436.58 11.835 3 8 1 215864 154 44 6 24.85 25.41 0 0 0 2933.33 4.555 4 1 1 214810 154 44 6 24.09 24.5 139 37 0 33603.61 21.645 4 2 1 239299 154 41 6 24.74 25.16 143 40 0 33161.25 25.035 4 3 1 271397 154 41 0 21.62 22.26 311 45 0 28011.73 24.245 4 4 1 280817 154 41 3 21.89 22.36 0 40 1 28316.82 27.645 4 5 1 284227 154 38 3 20.78 21.33 301 38 0 26578.44 28.895 4 6 1 308645 154 44 6 25.82 26.26 0 42 1 18945.13 22.695 4 7 1 308527 154 38 3 20.83 21.33 0 39 1 17862.96 23.375 4 8 1 433837 154 41 6 24.71 25.13 513 502 0 13012.83 18.47

Table L.1: Recording Index Listing

university of southampton faculty of engineering...

Documents