Development Standards & Practices Used

List all standard circuit, hardware, software practices used in this project. List all the Engineering standards that apply to this project that were considered.

• AGILE development
• Embedded programming
• UI/UX design
• Analog to digital conversion
• Serial communication
• Low-frequency analog design

Summary of Requirements

• MIDI guitar must look, feel, and play like a real electric guitar
• The system used to determine where each string is fretted, and therefore which MIDI notes are to be produced, must be implemented in hardware (henceforth referred to as note detection).
• Note detection system must accommodate the following playing styles:

• Single notes
• Open chords
• Bar chords
• Power chords

• The system used to determine when strings are being played by the user (henceforth referred to as strum detection) must operate independently of the note detection system, and meet the following requirements:

• Must allow user to play with a pick or with their fingers
• Must be able to detect relative volume (also referred to as intensity or velocity) of each string

• Overall system latency, defined as the amount of time between the user playing a note and the corresponding MIDI message being encoded and sent, must be under 10 milliseconds
• User must be able to use any brand or gauge of metal guitar strings
• User must be able to define the tuning of the guitar via software
• The MIDI interface will use MIDI over USB
• Final guitar must have between 18 and 24 frets

Applicable Courses from Iowa State University Curriculum

• EE 224
• EE 330
• CPR E 388
• MUSIC 246

New Skills/Knowledge acquired that was not taught in courses

• MIDI Protocol
• Woodworking

  ---

Table of Contents

1        Team        5

1.1        Team Members        5

1.2        Required Skill Sets for Your Project        5

(if feasible – tie them to the requirements)        5

1.3        Skill Sets covered by the Team        5

(for each skill, state which team member(s) cover it)        5

1.4        Project Management Style Adopted by the team        5

1.5        Initial Project Management Roles        5

2        Introduction        5

2.1        Problem Statement        5

2.2        Requirements & Constraints        5

2.3        Engineering Standards        5

2.4        Intended Users and Uses        6

3 Project Plan        6

3.1  Project Management/Tracking Procedures        6

3.2 Task Decomposition        6

3.3 Project Proposed Milestones, Metrics, and Evaluation Criteria        6

3.4 Project Timeline/Schedule        6

3.5 Risks And Risk Management/Mitigation        7

3.6 Personnel Effort Requirements        7

3.7 Other Resource Requirements        7

4  Design        8

4.1 Design Context        8

4.1.1 Broader Context        8

4.1.2 User Needs        8

4.1.3 Prior Work/Solutions        8

4.1.4 Technical Complexity        9

4.2 Design Exploration        9

4.2.1 Design Decisions        9

4.2.2 Ideation        9

4.2.3 Decision-Making and Trade-Off        9

4.3        Proposed Design        9

4.3.1 Design Visual and Description        10

4.3.2 Functionality        10

4.3.3 Areas of Concern and Development        10

4.4 Technology Considerations        10

4.5 Design Analysis        10

4.6        Design Plan        10

5  Testing        11

5.1 Unit Testing        11

5.2 Interface Testing        11

5.3        Integration Testing        11

5.4        System Testing        11

5.5        Regression Testing        11

5.6        Acceptance Testing        11

5.7        Security Testing (if applicable)        11

5.8        Results        11

6  Implementation        12

7  Professionalism        12

7.1        Areas of Responsibility        12

7.2 Project Specific Professional Responsibility Areas        12

7.3 Most Applicable Professional Responsibility Area        12

8  Closing Material        12

8.1 Discussion        12

8.2 Conclusion        12

8.3 References        13

8.4 Appendices        13

8.4.1 Team Contract        13

List of figures/tables/symbols/definitions

• Figures:

1. Overview of our project timeline.
2. Example of a MIDI Guitar with buttons.

• Log, Starr. “A New Ztar for Rob Swire of Pendulum.” Starr Log, 3 May 2011, http://starrlabs.blogspot.com/2011/05/new-ztar-for-rob-swire-of-pendulum.html.

3. Block diagram overview of our project.

• Tables:

1. List of tasks and the estimation of in-person hours required to complete said task.
2. Different areas of the world our project could impact, a description how our project could affect said area, and examples of why/how.

• Definitions:

1. MIDI

• Musical Instrument Digital Interface
• Standard that defines communication between a digital musical instrument and a computer. This standard defines how notes and other signals are encoded.

2. DAW

• Digital Audio Workstation
• Program that people use for creating music.

3. VST

• Virtual Studio Technology
• These are plugins that can be used with DAWs and MIDI instruments to turn the MIDI notes into different sounds.

4. DSP

• Digital Signal Processing
• In our case, this most likely refers to a Fast Fourier Transform, which looks at an audio signal and determines all of the frequencies present in that signal.

1  Team

1.1  Team Members

• Alec Meyer
• Ethan Cooper
• Hassein Rife
• Kyle Strozinsky
• Samuel Lavin

1.2  Required Skill Sets for Your Project

Analog Circuit Design

Embedded Software Development

UI/UX Design

Software Application Development

Wood Working

Digital Signal Processing

MIDI Processing

1.3  Skill Sets covered by the Team

Alec Meyer

Software Application Development

Embedded Software Development

Wood Working

Ethan Cooper

Digital Signal Processing

Hassein Rife

Analog Circuit Design

Embedded Software Development

Kyle Strozinsky

Software Application Development

UI/UX Design

Samuel Lavin

Digital Signal Processing

MIDI Processing

Embedded Software Development

1.4  Project Management Style Adopted by the team

Agile Development

1.5  Initial Project Management Roles

Alec Meyer

Software Testing

Software Development

Git Management

Ethan Cooper

Client Interaction

Hassein Rife

Analog Hardware Design

Hardware Testing

Kyle Strozinsky

Software Development

Software Testing

Samuel Lavin

Documentation

Team Organization

2  Introduction

2.1  Problem Statement

Our goal is to help guitarists who are not as fluent on keys as they are on a guitar. The problem these people are facing is that if they are music producers then they are at a disadvantage from those who use Midi keyboards. This is a global problem that people face all around the world. This problem is also occurring all the time as music production is becoming more accessible and popular. Because of its popularity, it is important to be as inclusive as possible. Our solution is developing a Midi guitar which allows guitarists an easier platform to produce music.

2.2  Requirements & Constraints

Our final project must be a functional guitar that would feel as if you are playing any other electric guitar when being played. The guitar’s strings must have realistic tension, and the added hardware must not add significant weight to the overall weight of the guitar. This guitar needs to output MIDI data to a software where the user can customize things like pitch, tone, and other attributes for music recording purposes. For example, a user may be able to change which note each string is tuned to, or what instrument sound is output, similar to an electric keyboard, all within an easy to understand and navigate software.

2.3  Engineering Standards

• IEEE 16085-2020: Risk Management

• The purpose of this standard in our project is to better assess the risks being taken in a management environment. Since this project has a large hardware aspect, a lot of risks will need to be taken as we cannot undo unneeded changes.

• IEEE 14764-2021: Software Life Cycle Maintenance

• The purpose of this standard is to better understand how a software (and hardware) projects life cycle will need to be maintained. Maintenance will be important for us specifically because we will be constantly iterating our designs and retesting our previous use cases.

• IEEE 26515-2012: Developing Documentation in an Agile Environment

• The purpose for this standard is to help write documentation for our team as the project develops. Documentation is extremely important for our project as we are combining technologies that are not familiar to everyone and especially the end user.

• Whitepapers from The MIDI Association:

• M1 v4.2.1 MIDI 1.0 Detailed Specification 96-1-4
• rp53 MIDI Polyphonic Expression
• General MIDI Level 1 Developer Guidelines

2.4  Intended Users and Uses

Musicians who wish to record music who are primarily guitar players benefit with this product. Most digital music composition options center around the ability to play piano. For those who do not know how to play the piano, this limits options and restricts the music that can be recorded by musicians. The ability to emulate a MIDI keyboard’s functionality within a guitar gives the ability to create quality digital music to a wider audience.

3 Project Plan

3.1  Project Management/Tracking Procedures

We are using agile methodology for our project. We chose this because it gives a clear idea of who needs to do what every two weeks, and gives us plenty of time to complete the issues assigned to us within those two weeks.

We will be using Git, Gitlab, Discord, and Google Drive throughout the project.

• Git: codebase management
• Gitlab: project boards, issues, and milestones (agile)
• Discord: team communication
• Google Drive: Document (files, not code) management

3.2 Task Decomposition

• Hardware

• Build note detection system.
• Build strumming detection system.
• Implement hardware into a guitar body.

• Embedded

• Write embedded C software to acquire information from hardware systems and format for serial transmission.
• Write embedded C code for serial transmission of MIDI encoded data between microcontroller and PC.

• Software

• Develop front-end to interface with microcontroller, send commands, and receive information.

3.3 Project Proposed Milestones, Metrics, and Evaluation Criteria

1. Note detection system must be able to detect changes in notes within a 1ms time period.
2. Note detection system must be able to work with a minimum of 6 strings and 22 frets.
3. Strumming and note detection systems must be able to differentiate between identical notes played on different strings.
4. Instrument must be contained in the body of a playable guitar with a single cable connected to an offboard processing box, which then communicates with a computer via a single USB cable.
5. Delay between playing a note and sending the encoded MIDI message must be no longer than 10ms.
6. MIDI capabilities of the instrument must be editable by software via a USB cable.

3.4 Project Timeline/Schedule

Fig. 1: Overview of our project timeline.

3.5 Risks And Risk Management/Mitigation

1. Note detection system must be able to detect changes in notes within a 1ms time period

1. Performance target may not be met: 0.4

2. Note detection system must be able to work with a minimum of 6 strings and 22 frets

1. May not be able to work with all 22 frets: 0.1

3. Strumming and note detection systems must be able to differentiate between identical notes played on different strings
4. Instrument must be contained in the body of a playable guitar with a single cable connected to an offboard processing box, which then communicates with a computer via a single USB cable.

1. May not be able to use a single cable between the guitar body and offboard processing box: 0.5

5. Delay between playing a note and sending the encoded MIDI message must be no longer than 10ms

1. Performance target may not be met: 0.5
2. Milestone may be delayed: 0.5

6. MIDI capabilities of the instrument must be editable by software via a USB cable

1. Can’t communicate both debug and MIDI info over single usb cable: 0.2

3.6 Personnel Effort Requirements

Table 1: List of tasks and the estimation of in-person hours required to complete said task.

3.7 Other Resource Requirements

The one thing our project will need is a working guitar body. A couple of our members have some guitar bodies that they would be willing to part with, but these may not be sufficient, and we may have to build something ourselves. If this was the case, we would need access to a shop with good quality woodworking equipment to build parts of our guitar.

4  Design

4.1 Design Context

4.1.1 Broader Context

Table 2: Different areas of the world our project could impact, a description how our project could affect said area, and examples of why/how.

4.1.2 User Needs

Guitar players need a way to use a guitar as a MIDI input because MIDI keyboards are not intuitive for them to use. Sure, they can use a MIDI keyboard as a MIDI input, however, this can hinder their workflow and dampen their creative ability. Finally, this guitar can open up a whole new world of possibilities in terms of live performance. Say a guitar player wants to play some crazy sound that’s only possible through a MIDI synthesizer; this guitar would allow them to do that while also maintaining a realistic guitar feel.

4.1.3 Prior Work/Solutions

MIDI guitars exist, but they consist of buttons on the neck and not real strings. Does not feel like you are playing a real guitar and can feel weird. There are also solutions that exist that use DSP to pull out the most prominent frequencies from a signal and then convert these to MIDI notes. These aren’t as accurate or as fast as what we are planning on doing, since our solution will be looking at exactly what fret the user is pushing down to determine what note they are playing.

Fig 2: Example of a MIDI Guitar with buttons.

4.1.4 Technical Complexity

Components/subsystems:

1. Note/Strum detection microcontroller

1. The scientific and mathematical principles for obtaining note detection are very advanced. This is why no one else has ever created a MIDI guitar of such caliber. This is not trivial.

2. MIDI encoding microcontroller

1. Encoding our raw data to MIDI is going to be an advanced circuitry task. This subsystem will either involve onboard encoding or a seperate chipset.

3. Software application for sending MIDI configurations to the MIDI microcontroller

1. This application will need to interface correctly with the MIDI encoding microcontroller to send it data which can be read in to adjust configuration.

4. Total Integration

1. Integrating all of these systems and components is also a non trivial task as data types and structures, along with physical limitations may apply.

4.2 Design Exploration

4.2.1 Design Decisions

1. How we are going to interface between the guitar and our off-board processing box. This will either be a standard connector like a 5-pin DIN connector, or a custom cable harness that we build ourselves.
2. How we will be interfacing MIDI with the computer. We can either have the note detection system and MIDI encoding system all on one microcontroller, or we will have to do the MIDI processing separately from the note detection system in order to reduce the load on the note detection microcontroller.
3. How our note detection system is going to detect notes (see below)

4.2.2 Ideation

Note detection

This is one of our biggest problems as the solution is not trivial. We have brainstormed many ideas in an informal sense and also siphoned those ideas into a structured framework like the lotus blossom.

Options:

1. Send a unique signal through each string and listen on frets
2. Send a unique signal through each fret and listen on the strings
3. Send a unique signal through each fret and string and listen at the nut to decode the sum
4. Send a signal through each string from the bridge and read the travel time to the nearest fret.
5. Send non-concurrent signals through each string and read
6. separating each fret into 6 sections.

4.2.3 Decision-Making and Trade-Off

We mostly made these decisions by communicating verbally with each other and describing the pros and cons of each decision.

4.3 Proposed Design

So far, our design consists of a test platform we built out of a piece of wood with two strings and four frets attached to it. This has allowed us to test various methods of note detection.

Currently, our design consists of 3 separate systems:

• Note detection
• Strum detection
• MIDI encoding

Note detection is the determination of what note(s) the user is playing based on where they are pressing down on strings/frets.

Strum detection is detecting when the user plucks notes, as a user pressing down on a fret doesn’t necessarily mean they are playing that note.

MIDI encoding is taking the information from the note detection and strum detection systems and shipping it off to the computer in MIDI format. We have not finalized how this system will work, but we suspect it will be on a different microcontroller from the first two so we can save some overhead on the note and strum detection. We are planning on using an open source library we found to send this data over usb to the computer.

4.3.1 Design Visual and Description

Fig 3: Block diagram overview of our project.

This block diagram shows a general view of the design we have worked out for our project. Information will start at the circuitry, which will be read by the first microcontroller, which will determine what note is being played based on the signals coming from the fretboard of the guitar. Then, the microcontroller will dump the note that is being played into a note buffer, where it will be picked up by another program/microcontroller that will convert this into a MIDI note, and send that off to the PC over a USB cable.

4.3.2 Functionality

The final product is intended to be used as someone would use any regular guitar, except that it will be used as a MIDI controller. This means that the user will take the guitar, plug the processing box into their computer, and use the guitar to send MIDI data to their DAW of choice to create music.

4.3.3 Areas of Concern and Development

Our only area of concern is note detection as the problem is not easy to solve. We believe that this problem is solvable and we have a few solutions ready, but they are workarounds. The immediate plan is to continue brainstorming a solution, but once development in other sections of the project continues, we will use one of the workaround solutions. We may also talk to some other professors to see if they have any ideas on a solution to our problem.

4.4 Technology Considerations

.Because of space and structural integrity considerations, the hardware in the guitar itself must be kept to a practical minimum in terms of size and complexity. Anything that doesn’t need to be local to the guitar itself will be contained in an external processing box.
It will be necessary to implement a string of resistors into the guitar neck itself. Because it will be nearly impossible to disassemble the neck after assembly, it is paramount that all hardware and electrical connections inside the neck be built to last, and able to perform in a variety of environmental conditions. We are prioritizing connection robustness, component lifespan, and low temperature coefficients in the hardware contained within the guitar itself, as there is no easy way to revise or repair the hardware internal to the guitar as there is with the hardware contained external to the guitar.
Because there will be a wire harness carrying signals from the guitar to the external processing box several feet away from the guitar, signal integrity is a consideration. As much as possible, we will be using DC or low-frequency signals between the processing box and guitar in order to preserve signal integrity between the two while minimizing the size and expense of cables contained within the wire harness.

The main technology used on the software end of this project is C#/.NET. The main strength with this language and framework is its immense documentation and also its large scale use in the technology industry. The only weakness of this tool is that the team is not familiar with it so it will take some time to perfect its usage.

4.5 Design Analysis 

Our proposed design has not been officially implemented yet. It has gone through several iterations however when it comes to our note detection and strum detection systems. After tweaking those issues we are confident in our final design for the product. If we need to further iterate our design, we have the product separated enough to be able to redesign specific aspects without interfering with other systems embedded in the guitar.

4.6 Design Plan

Fig 4: Component Diagram

Our current design plan has been to break our project into manageable functional components. Each of these components or subsystems are independent from each other which makes it much easier to test our designs and further our designs. This will also make it much easier to implement all of our subsystems into a final product. As seen in figure 4 Our total design has 4 functional components with 3 internal connections and one external output. All of these components can and will be engineered separately and concurrently.

5  Testing

5.1 Unit Testing

Our four main units to be tested are note detection, strum detection, midi encoding and the software application. The hardware aspects are being tested using written test cases and the software application will have a regression suite written for it as development continues. The tools used are our gitlab storyboard as each story will have its corresponding tests. We will have another (undecided) platform for recording physical tests.

5.2 Interface Testing

Strum detection and note detection are one main interface. This will be tested similarly to how they are tested separately. We will have a set of smoke tests for them and verify additions are working properly.  The second most important interface to test will be the connection between the microcontroller and the software application. The regression suite we write for the software application will have some coverage of the microcontroller, but will require some manual tests. Tools for the software testing might include Jenkins/xUnit. Tools for the hardware testing might include an oscilloscope.

5.3  Integration Testing

Our most critical integration path is connecting strum detection and note detection. Our plan for testing these will use their pre-existing test suites to verify singular performance. Then we will develop another test suite for the combined components. Tools for integration testing will be similar to the previous tools mentioned above.

5.4  System Testing

We have a very defined scope and heavy expectations for this project. This is all very well documented as well and will be used as a model for developing our system tests. Tools would include our previously created documentation along with gitlab stories.

5.5  Regression Testing

For regression testing we will have a new set of tests written for each and every gitlab story. For hardware, this will be a manual regression suite. For software this will most likely be setup as an automatic regression suite using GitLab CI/CD or another tool like Jenkins.

5.6  Acceptance Testing

We will carefully develop another regression test suite for acceptance testing along with our client to ensure our functional and non-functional requirements are being met. We will run through this acceptance testing regression suite at every major milestone to ensure conformance. We will also outsource our testing to another guitarist for verification.

5.7  Security Testing (if applicable)

There are no real security concerns in our application, so this is not applicable to our design.

5.8  Results

In our case we will have a set of tests for each story in gitlab. These stories are assigned to a single member and managed by that member. If a story has failing tests it is the owners duty to resolve these issues whether that is fixing them on their own or outsourcing their issue to another group member.

6  Implementation 

Our current implementation plan is to design and test each of the components separately this semester, then implement each subsystem and the final product during next semester. Our goal is to have everything theoretically designed and working to make our process of connecting technologies as seamless as possible. There is a lot to focus on outside of our  fields of study to focus on and we would like to make sure these external skillsets are given enough time to grow. For example, woodworking and general structural mechanics.

7  Professionalism

This discussion is with respect to the paper titled “Contextualizing Professionalism in Capstone Projects Using the IDEALS Professional Responsibility Assessment”, International Journal of Engineering Education Vol. 28, No. 2, pp. 416–424, 2012

7.1  Areas of Responsibility

We chose the SE code of ethics, and We will analyze Principle 3: Product.

7.2 Project Specific Professional Responsibility Areas

1. Work competence does apply to our project’s professional context. Everyone must be able to complete their work for the project to succeed as we all have different skill sets and rely on the work of others. We are performing high.

2. Financial Responsibility applies a bit to our project. We will have to make a few purchases, but it will be mostly cheap items for testing, but we will not need to make any significant portions until we begin working on a prototype. Performing highly.

3. Communication responsibility relates to our project a lot as we do not see each other every day. We must keep in touch to stay on the same page and ask for help. We are performing highly as we have been in close communication since the beginning of the semester daily.

4. Health, safety, and well-being somewhat applies to our project. There are not a lot of health or safety risks associated with our project. I’d say we are performing medium.

5. Property ownership does not really apply with the MIDI guitar. Most of the project will be made by the group and be owned by the group. So far it's NA.

6. Sustainability does not really apply to our project. MIDI Guitar does not have a significant environmental impact. Performance NA.

7. Social responsibility somewhat applies to MIDI guitar. There is a niche need for a product that we are making. We would categorize our performance as medium.

7.3 Most Applicable Professional Responsibility Area

Our group has demonstrated high proficiency in communication thus far. We have a discord server that we use daily as our primary source of communication. It means a lot for our project because it is how we will discuss things outside of class and meetings, as well it is how we will schedule meetings and discuss the project. We have dedicated channels for different aspects of the project, such as hardware, software, etc. Because we do not meet every day it is important to communicate fluidly to maintain efficient work on this project.

8  Closing Material

8.1 Discussion

There is a solid foundation for the end product of MIDI Guitar. We have established strum detection for individual strings and are making good progress on fret detection. These are the core requirements for this project and the rest of the assembly, along with 6 full strings and 24 frets, will be built atop the foundation we are completing.

8.2 Conclusion

Overall we have developed a solid foundation for this project to succeed. Note detection, which was our biggest challenge, has been solved and tested and strum detection is our next obstacle to overcome before next semester. We Have a good understanding of what needs to be done for the other remaining components for this project and have developed sufficient system testing plans for their total integration. Our plan going forward is to complete each component separately then integrate them together, treating this integration as its own sort of component.

8.4 Appendices

8.4.1 Team Contract

• Team Members:

• Alec Meyer
• Ethan Cooper
• Hassein Rife
• Kyle Strozinsky
• Samuel Lavin

• Team Procedures

• Day, time, and location (face-to-face or virtual) for regular team meetings:

• Tuesdays from 1:00pm to 2:00pm in the TLA; Thursdays from 1:00pm to 2:00pm in the SIC room 2233

• Preferred method of communication updates, reminders, issues, and scheduling (e.g., e-mail, phone, app, face-to-face):

• Email and Discord

• Decision-making policy (e.g., consensus, majority vote):

• Majority vote & consensus when necessary

• Procedures for record-keeping (i.e., who will keep meeting minutes, how will minutes be shared/archived):

• Samuel Lavin is in charge of minutes, and they will be stored on our Google Drive.

• Participation Expectations

• Expected individual attendance, punctuality, and participation at all team meetings:

• All team members are expected to attend both scheduled weekly meetings

• Expected level of responsibility for fulfilling team assignments, timelines, and deadlines:

• All team members are expected to complete their assigned tasks by their expected deadlines.

• Expected level of communication with other team members:

• All team members will be expected to communicate regularly through Discord/Email/In person meetings. All team members are expected to respond to any inquiry within 24 hours.

• Expected level of commitment to team decisions and tasks:

• All team members are expected to put forth their best effort and allocate a reasonable amount of time per week.

• Leadership

• Leadership roles for each team member (e.g., team organization, client interaction, individual component design, testing, etc.):

• Alec Meyer: Software development and testing
• Ethan Cooper: Client interaction
• Hassein Rife: Analog hardware design, testing, and interfacing microcontroller with analog
• Kyle Strozinsky: Git control
• Samuel Lavin: Documentation, team organization

• Strategies for supporting and guiding the work of all team members:

• Refer back to the participation expectations.

• Strategies for recognizing the contributions of all team members:

• Weekly stand ups to go over individual progress.

• Collaboration and Inclusion

• Describe the skills, expertise, and unique perspectives each team member brings to the team.

• Alec Meyer: Software testing, application development, guitar, musician
• Ethan Cooper: Musician, DSP
• Hassein Rife: Guitar, musician, analog design
• Kyle Strozinsky: Guitar, musician, application
• Samuel Lavin: Guitar, musician, DSP, MIDI, VST

• Strategies for encouraging and support contributions and ideas from all team members:

• Everyone is expected to ask questions and pitch ideas for each idea presented

• Procedures for identifying and resolving collaboration or inclusion issues (e.g., how will a team member inform the team that the team environment is obstructing their opportunity or ability to contribute?)

• Speak openly about it and just let the team know what is going on.

• Goal-Setting, Planning, and Execution

• Team goals for this semester:

• Complete a theoretical prototype

• Strategies for planning and assigning individual and team work:

• Weekly meetings and utilizing Agile framework

• Strategies for keeping on task:

• Weekly meetings and utilizing Agile framework

• Consequences for Not Adhering to Team Contract

• How will you handle infractions of any of the obligations of this team contract?

• Speak with team member and let them know they are not upholding the team's expectations

• What will your team do if the infractions continue?

• Reassign stories and tasks assuming work will not be completed, and note failure to comply in weekly reports/advisor meetings

1. I participated in formulating the standards, roles, and procedures as stated in this contract.
2. I understand that I am obligated to abide by these terms and conditions.
3. I understand that if I do not abide by these terms and conditions, I will suffer the consequences as stated in this contract.