Software-Based Guitar Sound Effects SynthesizerProject Design Report

May01-17

Faculty Advisor, Client: Stephenson

Kevin CrottyLukasz DarowskiNathan Linquist

Daniel McPartlandSriram Narayanan

11/28/2000

List of Figures____________________________________________________________________2

List of Tables_____________________________________________________________________2

Abstract___________________________________________________________________________1

Acknowledgement________________________________________________________________1

Definition of Terms______________________________________________________________1

Introduction_______________________________________________________________________2

General Background_________________________________________________________________2

Technical Problem___________________________________________________________________3

Operating Environment______________________________________________________________3

Intended Users______________________________________________________________________3

Assumptions and Limitations__________________________________________________________3

Design Requirements____________________________________________________________4

Design Objectives____________________________________________________________________4

Functional Requirements_____________________________________________________________5

Design Constraints___________________________________________________________________5

Design Milestones____________________________________________________________________6

End Product Description_________________________________________________________7

Approach and Design____________________________________________________________8

Technical Approach__________________________________________________________________8

Technical Design____________________________________________________________________9

Testing Description_________________________________________________________________14

Risk and Risk Management__________________________________________________________15

Recommendation for Continued Work_________________________________________________16

Financial Budget________________________________________________________________17

Personnel Effort Budget________________________________________________________17

Project Schedule_________________________________________________________________18

Project Team Information______________________________________________________19

Summary_________________________________________________________________________19

References_______________________________________________________________________19

Appendix A______________________________________________________________________20

i

List of Figures

Figure 1. Physical Multi-Pedal Model___________________________________7Figure 2. The software-based guitar effects synthesizer system_______________9Figure 3. The Cypress EZ-USB FX development board____________________10Figure 4. Effects patch______________________________________________11Figure 5. Block diagram of an effect object______________________________11Figure 6. The digital signal processing and GUI interface___________________14Figure 7. Gant Chart_______________________________________________18

List of Tables

Table 1. Estimated monetary cost of the project__________________________17Table 2. Estimated time expenditure for each team member for the project_____17Table 3. Contact information for each member of the team__________________19

ii

Abstract

The existing technology used to create guitar sound effects is often prohibitively expensive to the amateur guitarist. The object of this project is to provide an affordable alternative that uses the computational power of modern personal computers to simulate guitar effects. The universal serial bus (USB) provides a fast interface with the PC, allowing for real time communication with the multi-effects pedal. Through this interface, the computer modifies the guitar signal based on mathematical models for each effect. This software implementation will enable the addition of other effects in the future.

Acknowledgement

The GFX team would like to extend thanks to Cypress for the donation of their EZ-USB microcontroller and accompanying development board. We would also like to thank Keil Company for donating software development tools.

Definition of Terms

chorus A sound effect which modifies a guitar’s output signal by adding an out of phase delayed signal on top of the original signal to create the effect of having more than one guitar.

delay A sound effect that overlays the signal with a very slightly delayed (less than 50 ms) version of the signal.

distortion A sound effect that modifies the sound of the guitar by changing the amplitude characteristics of its signal. Originally discovered by driving vacuum tubes into their breakdown region. This effect is often used to create a “metallic” sound in heavy medal music.

echo A sound effect created by delaying the input signal 50 ms or more, then mixing then mixing it with the current signal. This delay will cause the listener to hear an echo.

equalization A sound effect created by boosting or cutting certain frequency components of a signal.

flange A sound effect that creates a “whooshing” sound by interfering a delayed signal with the original signal.

multi-pedal An arrangement of two or more pedals.

noise gating A sound effect created by either attenuating or amplifying a signal if it is either above or below a given threshold.

pedal The pedal is a foot operated digital switch that is used to select effects.

reverberation A sound effect that mimics the result of reflections of sound within a room to create a feeling of spaciousness.

USB Universal serial bus - This is a data bus that provides reasonably fast data transfer between a host PC and a peripheral device.

wah A sound effect that dynamically changes frequency response in response to the position of an analog switch.

Introduction

General Background

Rock and roll music is dominated by electric guitars. A major reason for the guitar’s popularity is the broad range of sound effects available to musicians by electronically modifying its signal. The sound effects range from simple overdriven distortion to complex chorus and echo effects. Traditional effects pedals are based on analog electronic circuits which are connected serially to provide different combinations of effects. Such devices are usually expensive and can perform only one particular effect at a time. The combination of more than one effect requires the purchase of more hardware, which in turn increases the total cost. In practice, an average guitar player needs to invest a lot of money into hardware before he can start making a wide variety of music. To solve the problem of high cost, a new solution is needed.

Based on advances in desktop computing, a modern PC has enough computing power to modify the digital sound without noticeable latency. Using an inexpensive electronic circuit, the guitar signal can be forwarded to a PC, which in turn modifies the signal and outputs the desired sound effects back to the device, which can the be plugged into a standard guitar amplifier. Mechanical pedals will provide the switching mechanism between different sound effects and may be programmable by the host. This approach takes advantage of the common availability of PCs, offers a modifiable and extensible method for synthesizing guitar effects, and saves money by providing one device that create entire suites of sound effects at the same time.

Technical Problem

The guitar effects synthesizer can be divided into two parts: hardware and software. The hardware will include mechanical pedals for switching between sound effects, a digital to analog converter, an analog to digital converter, and a USB microcontroller. Because the software based guitar effects synthesizer will use USB communication to transfer data between the PC and the pedals, the host PC must run Windows98 or later model Windows operating system with USB support.

The graphical user interface, the mechanism through which the computer user communicates with the software based guitar effects synthesizer, will be created with LabVIEW software. The computer monitor will be used to display the current list of effects, and standard input devices such as a keyboard and a mouse will allow the user to interact with the system.

The electronic device will be powered directly by the USB, so that no external power supply will be needed. The key step on the software development side of the project will be to successfully interface the USB microcontroller with the host PC. After that milestone is completed, specific digital signal processing algorithms can be used to create the range of desired sound effects.

Operating Environment

The guitar software-based effects synthesizer will be expected to operate within a temperature range of 0 degrees Celsius to 40 degrees Celsius. The device is not expected to be exposed to water, although it is expected to operate effectively in high humidity environments. Due to the electronic nature of the device, it must tolerate an environment that includes electromagnetic interference from other devices that may be present, including 60 Hz power lines.

Intended Users

The software-based guitar effects synthesizer is intended for amateur guitarists with limited budgets. The synthesizer is expected to be an affordable alternative to analog pedals currently available to this group of guitarists.

Assumptions and Limitations

The software-based guitar effects synthesizer project is based on the assumption that many amateur guitarists own a personal computer that meets the following limitations:

The PC must be USB compatible

The PC must operate on Windows98 or newer operating system. The PC must have a minimum processor speed of 500 MHz. The PC must have at least 64 megabytes of RAM.

The sound quality of the software-base guitar effects amplifier will be limited by the resolution of the analog to digital converter, as well as the digital to analog converter used to input and output the signal. It will also be limited by the frequency at which the guitar’s signal is sampled. In order to accomplish this, sampling must be done more frequently than the most frequent audible sound. Because this frequency is approximately 20 kHz, the minimum sampling frequency will be limited to 20 kHz. Finally, the total number of sound effects that can be applied will be limited by the speed of the host PC and the complexity of the processing algorithms such that the maximum latency will be 10 ms.

To eliminate design complexity, the number of effects that can be sequentially chained together will be limited to eight. To further reduce the complexity of the design, the total number of chains of effects that can be mapped to one pedal will be limited to eight as well. Because the number of pedals on the physical multi-pedal is limited to three, this limits the total number of programmed effects available to the user at any give time to twenty-four.

Design Requirements

Design Objectives

1. The Guitar Effects Synthesizer must be easy for the guitar player to use.Because guitar players are accustomed to using standard analog pedals to produce their guitar effects while playing, the design must present a mechanical interface that is similar to what is currently on the market.

2. The Guitar Effects Synthesizer must have an easy to use software interface.Because the user of the Guitar Effects Synthesizer will use a software interface to map various effects onto the multi-pedal, the synthesizer must have an interface that is easy for the guitar player to use.

3. The Guitar Effects Synthesizer must support a wide berth of effects.One of the main advantages that a PC based synthesizer has over typical analog synthesizers is that an unlimited number of effects could be programmed into the computer. To take advantage of this, the design must be extensible to allow for the implementation of many different effects.

4. The Guitar Effects Synthesizer must be inexpensive.

Current guitar effects are often very expensive. Given the relatively small amount of hardware necessary to implement this system on the PC, the cost of the design can be kept low to be competitive in the market.

Functional Requirements

1. The user interface must allow users to switch and chain effects.One common practice among guitar players is to hook multiple effects together in a chain. In order for the software-based design to produce the same effects, it must also allow the user to mimic the same configurations. This means that the user interface must allow the user to specify which effects he wants, and must allow him to specify the order in which the effects are processed from the software interface. He must also be able to configure the pedals to control the effects while playing. The effects supported must include distortion, noise gate, chorus, reverberation, echo, delay, flange, pitch shift, equalizer, and wah.

2. The pedals must be programmable.The guitar effects synthesizer will have only a small number of pedals compared to the number of effects that can be supported. Because of this, the user must be able to program which effect is controlled by which pedal at any given time.

3. The synthesizer must correctly sample the input from the guitar.The synthesizer must accurately read the output from the guitar, or its output will not be acceptable to the guitar player, regardless of what effects are applied to the signal.

4. The software must correctly process the input based on the user’s chosen effect.The major function of this system is to process the guitar’s signal to give it certain effects. The software-based synthesizer must apply the effects the user chooses. Without this feature, the synthesizer would basically be non-functional.

5. The guitar effects synthesizer must output the processed signal.The output from the synthesizer must be fed into current analog amplifiers. Because of this, the synthesizer must convert its digital signal into an analog signal that can then be input into any standard electric guitar amplifier.

Design Constraints

1. The guitar effects amplifier must have negligible latency.The speed at which the synthesizer can produce its output is very critical to this application. A long time delay from the time the signal is input into the system until the synthesizer produces its output will cause the sound produced to lag behind what the guitar player is playing. This would be unacceptable to the

musician. To prevent this from happening, the design must be implemented such that the maximum latency is less than 10 ms.

2. The guitar effects amplifier must be USB compatible.The analog signal from the guitar must be digitized, and then input into the user’s PC. This will be done via the PC’s USB. In order to accomplish this, any part of the synthesizer outside of the PC must be USB compatible.

3. The system must operate in normal PC environment.The guitar effects synthesizer must work properly in the same physical environment that one would expect to use a PC in (0ºC to 40ºC). This includes the assumptions that the system will not be exposed to extreme temperatures, and the system will be used only in dry environments.

4. The size of the program running on the USB microcontroller must be less than 2 kB.Because the software development package that we received with the Cypress EZ-USB microcontroller is an evaluation copy, it will only compile programs that are less than 2 kB long. Thus, the microcontroller program is limited to that length, unless a full version of the compiler is obtained.

Design Milestones

1. The hardware to be used in the system is selected.Hardware outside of the PC will be needed to sample the guitar’s analog output, convert it to a digital signal, and interface it with the USB. This includes the microcontroller and development board as well as an analog to digital and a digital to analog converter for the effects unit. The selection of the particular hardware is critical to the synthesizer’s functionality, and also must precede much of the programming work that can be done.

2. The development environment is selected.Once the hardware, which will consist primarily of a microcontroller, has been selected the team must choose an environment in which the software for the microcontroller can be written and tested. The selection of an appropriate development environment is therefore critical to the design of this synthesizer.

3. Communication must be established between the PC and the synthesizer’s microcontroller.

The communication between the PC and the microcontroller is critical to the system. The digital signal must be transferred to the PC as well as information about the multi-pedal. If communication between the two devices cannot be established, then there is no chance the system will function.

4. The guitar effects signal processing algorithms are implemented.

Audio InAudio Out

USB I/O

Digital Switch Pedals

Expression Pedal

Once communication has been established between the PC and the synthesizer’s microcontroller, the PC must process the input signal. Therefore, correct implementation of the algorithms that will accomplish this is the next major step in the project.

5. The graphical-user interface is implemented.The final major step in the project will then be implementing the graphical interface that allows the user to select effects and map them onto the multi-pedal. Once this milestone is reached, the system should be functional.

End Product Description

The Guitar Effects Synthesizer will consist of two major parts. The first of these parts is a physical multi-pedal as shown in Figure 1. This pedal must have a standard quarter inch analog in jack and a standard quarter inch analog out jack. The device must also have a USB interface, to allow it to exchange data with the personal computer. The multi-pedal will consist of three digital switches, or pedals, which will allow the user to control his or her guitar’s effects while he/she is playing. The multi-pedal will also have one analog “expression” pedal for control of the wah effect. This device will attach to the PC using a standard USB cable. Refer to Figure 1 for physical layout of the multi-pedal’s components.

Each of the three digital switch pedals will be programmable with up to eight user-defined effects. The user will specify these effects through the PC software before the system begins operation. To switch effects, the user must press one of the pedals. This action will increment the user through the list of effects programmed to that particular

Figure 1. Physical Multi-Pedal Model

pedal. If the user then steps on a different pedal, the guitar effect synthesizer will then apply the first effect in the list of effects specified for that pedal to the output signal. Subsequent depressions of that pedal will then sequentially apply the other effects in the pedal’s programmed list.

To use the system, the user must be able to specify what effects are mapped to each pedal, and also the order in which these effects will be associated with each pedal. This will be done through the PC’s graphical user interface (GUI). This interface will allow the user to chain together effects and to make a list of these effect chains for each pedal. Once this specification is done, and the system is started, the user will then be able to control the effects applied to the system through the multi-pedal while he/she play the guitar.

Approach and Design

Technical Approach

The technical approach used by the software-based guitar effects synthesizer team is that of a two-computer system as shown in Figure 2. As shown in the figure, a microcontroller embedded in the multi-pedal will sample the electric guitar’s output at a frequency of 44 kHz. This data will be saved in a buffer in the microcontroller’s buffer. Every one millisecond this data will be sent to the PC as well as data regarding the status of the pedals via the USB. Once arrived at the USB, the data will be sent to the digital signal processing section of the PC program. Here, the data will be modified based on the user’s input regarding the effects mapped to each pedal. Once the data has been modified, it will be sent back to the pedal’s microcontroller, again using the USB. The microcontroller will then route the data to a digital to analog converter, again at a frequency of 44 kHz. This converter will be attached to the analog output jack, which the user can then attach to any analog output device.

Because the guitar effects synthesizer was proposed to work using the PC’s USB interface, the number of different technical approaches available to the team became very limited. This is due to the fact that the USB interface supports only the transfer of digital data. Because of this, the need for an analog to digital converter to digitize the guitar’s output became apparent. The next constraint limiting the number of possible approaches is that the USB only transmits data once every 1 ms. Because of this, and the necessity to sample the data at a significantly higher frequency than 1000 Hz (1/1ms), the idea of using a microcontroller to control data acquisition and transmission became apparent.

To help reduce the complexity of the system, the team approached the problem by breaking the system into three major components. The first of these components is the physical multi-pedal (microcontroller, A/D and D/A converters) combined with all USB programming. The second component consists of the signal-processing portion of the program. The third and final component of the system is that of the graphical user

interface. The modular design was chosen because it allowed the team to develop the various modules in the system using a parallel approach, rather than a sequential approach to the design and development of the system. This approach was chosen

because it allows the entire team to have an active roll in the development of the system. This approach will also help the team develop the system in a more efficient manner, because it allows development to continue with the system, even if there is a problem

with one module in the system. Such a problem could stop all progress had the team chosen a sequential approach.

Technical Design

After the team had decided on which approach to use in developing the system, the next step in the process was to design each module within the system. The major focus of this effort was to design both the modules, and also the interfaces between various modules. The following section will present the alternative designs considered for each module as well as for the interfaces between various modules. It will then specify which design the team has selected, as well as the criteria used to select each design.

ModulesThe Multi-Pedal Module

The multi-pedal module’s design focuses around the microcontroller embedded in the physical multi-pedal. This microcontroller will be programmed to sample the guitar’s output and write data to the digital to analog converter at a frequency of 44 kHz. This will be done using a Cypress EZ-USB microcontroller. The development will be done

Figure 2. The software-based guitar effects synthesizer system. The arrows represent the flow of data within the system.

using the EZ-USB FX development board, number CY3671, also from Cypress. This development board is shown in Figure 3 on the following page. All programming done on the microcontroller will be done in either C or assembly language, using Keil’s Vision2 compiler that was included with the development board. The team considered using several different USB compatible microcontrollers, however the Cypress processor was chosen due to the extensive documentation that was included with the development package. Because this component controls all data input and output for the system, reliability is extremely important. By using such a well-documented development kit, which includes some nice debugging tools, the team hopes to ensure that no unforeseen problems arise.

The other major function of this module is to facilitate the flow of data between itself and the digital signal-processing module. To do this, a device driver must be provided. There were several alternative suggested for this portion of the module. These alternatives were to write a new driver, try to format the data to fit pre-existing audio formats, and use a generic Windows driver, or finally to use (possibly with modifications) a generic driver provided with the microcontroller’s development kit. The team decided on using (possibly with some modification) the generic driver provided with Cypress’s development kit. The decision to use this driver was made because of the lack of driver-programming experience within the team. Another reason for this decision is that the development of the system is being done on the team’s own computers, and a faulty driver could cause a team member’s system to crash. Thus, the team was hesitant to experiment with writing new drivers from scratch.

Figure 3. The Cypress EZ-USB FX development board.

The Digital Signal-Processing ModuleThe second module designed was the digital signal-processing module. The major

function of this module is to modify the data supplied by the multi-pedal module, and modify in accordance with the effect that has been programmed and selected by the user. There were several different designs considered for this module. The first of these decisions was whether to use procedural or object oriented programming. To decide

EFFECTOBJECT

EFFECTOBJECT

EFFECTOBJECT

. . . . EFFECTOBJECT

Effect Name

Parameter 1

Parameter 2

Parameter 3

Parameter …

Parameter n

which design technique to use, the tradeoff between the simplicity of writing procedural code and the possible run-time speed advantage was weighed against the planning and memory management advantages of using an object oriented design. Because there is a time frame of several milliseconds for each group of data samples to be processed, the team decided in favor of using the object-oriented approach.

The next major design alternative considered involved the situation when the user wanted to chain more than one effect on a particular pedal. One alternative was to allow the user to choose the effects, but to have “hard” ordering, so that the user could not specify the order that the effects were applied to the signal. The other alternative was to design a scheme so that the user could specify the order of effects. To choose between these two alternatives, the team decided that although the “hard” ordering would be much simpler to program this ease of implementation was outweighed by the flexibility to the user provided by programmable ordering.

To handle this flexible ordering, the team then had to design a data structure that would allow the digital signal processing algorithms to dynamically decide which order to process the effects should be applied to the signal. The team developed the idea of an effects “patch.” This patch is a data structure that contains an ordered list of effect objects, as seen in Figure 4. The effect objects consist of the effect name and parameter list as their data members as shown if Figure 5. Therefore, by allowing the user to order the effects, then creating a patch with the same order as the user-ordered list of effects, the order of the effects can be maintained by executing one of these patches.

Figure 4. The effects patch.

Figure 5. Block daigram of an effect object.

The final major design alternative was how the digital signal-processing algorithms would be notified of which effect on which pedal was currently selected. There were three major alternatives were suggested. The first of these was to have to keep track of which pedal was selected in the GUI. To do this, the GUI would have to read the pedal status from the multi-pedal, then the digital signal-processing algorithms would have to call a function to get the current patch from the GUI. This implementation was not chosen because it is very complex, and would involve a high amount of overhead to complete all of the required communication. The next alternative suggested was to have the multi-pedal keep track of which pedal was selected. To do this, the GUI would have to send information about how the pedals were configured to the multi-pedal. Then, the multi-pedal would send the processing algorithms the patch information along with the data samples. Again, the complexity of the communication involved in this implementation was considered too difficult. Instead the team opted for the third alternative, in which the pedal information is actually kept within the signal-processing portion of the algorithm.

To accomplish this, the user configures the pedals using the GUI. The patches created by the GUI, corresponding to this configuration are then stored in three arrays in shared memory, one corresponding to each of the digital pedals. Each time a pedal is activated, the multi-pedal will send the signal-processing algorithms information about which of the pedals was activated. The processing algorithms will use that information to index through the arrays of patches, thereby allowing it to select the appropriate patch. This approach was chosen because of the reduced communication overhead involved, and the comparative simplicity of its implementation.

The final design alternative considered for this module is that of using either the C++ language or the LabView programming language to implement the processing functions. LabView has the advantage of having many digital-signal processing functions built into the language. However, this is fairly complex software, and the team is unsure whether it will be able to process the data fast enough to allow the system to run successfully. Because of this, the team has decided to use the C++ alternative. The use of this language should result in faster data processing, which should allow the system to operate with tolerable delay. The team however, is still considering attempting to prototype several signal-processing functions with LabVIEW to test its speed.

The Graphical User Interface ModuleThe final module designed was that of the graphical user interface. This is the

module that the user of the guitar effects synthesizer will interact with in order to create his/her effects, and to map them onto each pedal. The design of this portion of the system must be easy for the user to understand, easy for the user to use, and must be able to create patches complete with correct order and complete with all user-defined parameters. To create this module, there are two main designs under consideration.

The first of these is to implement the GUI using LabVIEW, a graphical programming language. This software package would allow the team to create a GUI, where the user could create chains of effects by physically linking icons, representing

different effects, in the order desired. The user could then adjust any of the effects’ parameters to tailor each effect. This implementation would provide the user with a very intuitive way to create effects chains, and as such would have the benefit of being very easy to use. However, this implementation could be very complex from a programming standpoint, given the team’s lack of LabView programming experience.

The other alternative under consideration is to implement the GUI using the Visual C++ programming language. This programming language also will allow the team to design a fairly graphical GUI, although it would not be as graphical as the LabView alternative. This would make it more difficult to a very intuitive, easy to use interface for the user. However, the team has more experience using Visual C++, and implementation of this alternative is unlikely to be as complex as the LabView alternative. The team is still in the process of weighing the advantages and disadvantages of each of these alternatives.

How the System WorksThe design for each of the guitar effects synthesizer’s modules has been

described. The next several paragraphs will demonstrate how each of the individual modules of the system are combined to work together to create the functioning system.

When the user starts the system’s software, he or she will be presented with the GUI. This screen will allow that user to create new effects, or chains of effects and map them to the three digit pedals. The GUI will also allow the user to load a pre-saved configuration, or pre-saved individual effects. Once the user has specified his/her desired configuration, he/she will start the system by taking some action (such as clicking a start button) on the GUI. On this action, the GUI will create patches that correspond to each effect that the user has specified, and place them in memory shared with the signal processing algorithms in order corresponding to the order the user has configured the pedals.

Once the signal processing algorithms have access to the pedal configuration patches, it will begin to read the sampled data and pedal information from the multi-pedal. This will be done by calling functions that return the desired data from the multi-pedal’s driver. This event should happen once every 1 ms. At this same interval, the signal processing algorithms should also send modified data back to the multi-pedal, again via functions provided by the pedal’s driver. Once the signal-processing algorithm has the data from the guitar, and also data about the pedals’ behavior, the correct patch can be selected and executed to appropriately modify the data. This cycle of reading data and writing data will continue until some action (such as hitting a stop button) is taken to stop the system via the GUI.

On system start up, the host PC will initialize the microcontroller in the multi-pedal. From this point in time, it will sample its input and write one data sample out to the output with a frequency of 44 kHz. Once every 1 ms, the microcontroller will send the most current batch of data samples to the signal processing module via the USB. At the same time, it will receive a new batch of modified data, to be output in the next 1 ms.

G U I

EFFECTEFFECT EFFECT . . . . EFFECT

. . .

Patch

DSP

Function Pointer Array

Functions

This process will continue until the system is stopped. Through the above actions of each individual module, and the interactions between the three modules, the system should produce the correct output within acceptable time limits.

Testing Description

There are many components of the system that must be tested and working correctly before the system can work correctly. In order to obtain accurate sample of the data, the analog to digital conversion must work correctly. Testing of this hardware is as simple as sampling a known voltage, and testing whether the correct digital result is obtained. By running this test over the range of voltages expected from the guitar, it is possible to verify that the A/D converter will in fact correctly convert all needed voltages.

Figure 6. The digital signal processing and GUI interface. The arrows in the diagram indicate data flow.

Another piece of hardware that must function properly is that of the digital to analog converter. To test this hardware, digital values over the range of expected output of the system can be sent to the D/A converter, and its output measured with an oscilloscope or multi-meter. This process can be used to verify that the D/A converter will work over the entire range of voltages that the system is likely to produce.

The latency of the system is another key characteristic that must be tested. An oscilloscope will be used to determine the amount of time that elapses between the time a signal is sampled, and the time that it is output. The team’s goal is to keep this time under 10 ms. Along with the oscilloscope test, the team plans to perform acceptance tests on the latency of the system by having guitar players use the system, and questioning them about whether the system’s latency is acceptable.Another concern is that of the correctness of the output. To test this, an oscilloscope will be used to compare the output of the software-based guitar effects synthesizer with that of standard analog devices. This test will be used to determine if the modifications to the waveform are consistent with current standards. After this, guitar users will again test the system and their input concerning the sound of the effects will be noted.

The graphical user interface is one other component of the system that must be tested. To test this system, users will be asked to use the system. By questioning these users about the system’s usability, the team hopes to ensure that the end product will meet the majority of users ease-of-use expectations. The users’ comments will be logged, so that they can be referenced and fitting improvements can be made to the system.

The communication between each module is the last area where testing will be required. To test this aspect of the project, the data passed from one module to another will be recorded before it is transmitted. After transmission, the data that arrived at the destination module will be recorded, and then compared to the data recorded before transmission. The system will pass the test if the data collected at each place in the system is the same.

After each component of the system has been tested, the team will perform test the usability of the entire system. Again, the team will allow users to actually use the entire system. These users’ comments on the overall usability will be noted, and any major problem area can then be addressed. The form used to record this test can be seen in appendix A.

Risk and Risk Management

There are several risks faced by the team in the development of the software-based guitar effects synthesizer. The first of these risks is that any of the individual team members may not stay on task as the project is developed. This is a very important risk, because the team has divided the workload into three major categories. Work on these three areas is expected to proceed in a parallel manner. If one group does not complete their part of the project, then the entire project is in jeopardy. To minimize this risk, the

team emphasizes attending frequent meetings where the progress of each team member is discussed. This encourages all team members to stay on task. It also give the team a chance to spot a potential problem before it is too late, thereby leaving time to take corrective actions.

The second major risk faced by the team is that of unsuccessful technical designs. This risk is very significant because the success of the project is directly related to its design. If the design is flawed, then the product will have a very small chance of succeeding. To minimize this risk, the projects design, and possible alternative designs, were discussed in great depth by all members of the team. By having lengthy discussions the team hoped to spot any large flaws in the design. To further reduce this design, the team must begin implementation as soon as possible, so that any flaw that may remain in the design can be diagnosed while there is an adequate amount of time to redesign that aspect of the project.

The final risk faced by the team is that of hardware breakage or malfunction. The design of the project is very dependant on the hardware (most importantly the Cypress microcontroller and development board). The functionality of the hardware that the team has already obtained if critical because of the team’s limited financial resources. If this hardware were damaged, this part of the project would stall while the team tried to find more donated hardware. Unless the team obtained an exact replacement for the damaged hardware, it is possible that all development on this portion of the project may be rendered useless. To minimize this risk, all development on the hardware will be done in one place, so as to eliminate the risks involved with the transport of the hardware. It is also expected that team members will use extreme caution while working with this board, and thoroughly test any hardware that will be attached to it to ensure its safety.

Recommendation for Continued Work

At this time, the team recommends that the project continue as originally planned. The team has encountered no major problems that would lead to the conclusion that the completion of the project, as planned, is not obtainable.

Financial Budget

Table 1. Estimated monetary cost of the project.

Item Original Estimated Cost Revised Estimated CostUSB Microcontroller and Development Board

$200.00 $0.00 (actual cost)

USB Cables $20.00 $20.00Casing $20.00 $20.00Other Hardware $50.00 $30.00Poster $50.00 $120.00 (actual cost)Total Cost $340.00 $190.00

The major difference in the revised estimate of cost, as seen in Table 1 above, for the project is due to the donation of a USB microcontroller and development board by Cypress. The donation of this hardware eliminates all of the cost that the team had originally planned on incurring for this hardware. The other major difference is in the cost of the poster. Due to time constraints, the team was forced to print the poster off campus, which more than doubled the price. Finally, the small change in expected cost of other hardware is due to the fact that the team was able to obtain free samples of the A/D and D/A converters necessary for the project.

Personnel Effort Budget

Table 2. Estimated time expenditure for each team member for the project.

Personnel Effort Budget Original Estimated Effort Revised Estimated EffortKevin Crotty 330 hours 315 hoursLukasz Darowski 327 hours 300 hoursNathan Linquist 330 hours 310 hoursDan McPartland 350 hours 330 hoursSriram Narayanan 314 hours 314 hoursTotal Estimated Effort 1651 hours 1569 hours

The estimates of personal time expenditure, shown in Table 2 above, are based on the amount of time that each team member believed was necessary to complete the project. It was also based on the amount of time each team member felt that they would have available to work on the project. The total estimated amount of time necessary for the project had decreased from original estimates due to a feeling among the team that the original estimates were slightly exaggerated.

Project Schedule

This Gantt chart shows the team’s updated project schedule. The updates are shown above their original projections. The team is well ahead of schedule for procurement of parts. Most other parts of the schedule are slightly behind their projected dates, but still acceptable. The delays resulted from unforeseen job interviews, scheduling conflicts, difficulties with Microsoft Word, and other rigors of an active college life.

Figure 7. Gantt Chart

Project Team Information

Table 3. Contact information for each member of the guitar effects synthesizer team.

Name Mailing Address: Telephone Email MajorKevin Crotty 205 S 5TH ST #902

AMES, IA 50010 515-233-9391 kcrotty@iastate.edu Cpr E

Lukasz Darwoski 4409 FRILEY LINCOLNAMES, IA 50012

515-572-5515

dlukasz@iastate.edu Cpr E

Nathan Linquist 610 SQUAW CREEK #20AMES, IA 50010

515-233-6527

nlinquis@iastate.edu

Cpr E

Daniel McPartland 131 CAMPUS AVEAMES, IA 50014

515-292-6248

dmcpartl@iastate.edu Cpr E

Sriram Narayanan FRILEY 2211 PEARSON, AMES, IA 50012.

515-572-5504 snarayan@iastate.edu Cpr E

AdvisorDr. Stephenson 1419 COOVER

AMES, IA 50011-3060515-294-2726 stephens@iastate.edu Advisor

Summary

The true power of the modern computer lies in its versatility. The enormous computational power of common personal computers and the impressive bandwidth of modern bus architectures can be harnessed to create new inexpensive products that are more versatile and user-friendly than currently existing products. This is what the software-based guitar effects synthesizer, as designed as proposed in this document sets out to accomplish. If this goal is met, the amateur guitarist will be able to use a PC, with the software-based synthesizer to replace a large number of individually costly, and less versatile pieces of hardware.

References

http://geofx.com/effxfaq/fxdescr.htmhttp://www.harmony-central.com/Effects/effects-explained.htmlhttp://www.smartelectronix.com/musicdsp/

Appendix A

Senior Design Project Detailed Test Form

Tester's name:

Date: Time:

Detailed Test Description:

Failure Description:

Additional Comments: