7 • Discussions
7.0 • Hardware
7.0.1 • Design
The hardware portion of the AutoTabber project went through two different design phases. The original idea for the hardware was to gut an existing electric bass guitar, and replace any internal hardware used for audio playback through an amp, with our own hardware. In this way, the instrument would have become simply one used for writing music, which just isn’t ideal. An all-in-one package that could be used as a normal guitar as well as with the software was a better choice. Also, this original idea proposed to hollow out the neck of the bass for wiring to travel through. With the small size of the neck of the guitar, this was a dangerous proposition. A mistake could mean ruining a perfectly good bass guitar. It was decided that the wiring would travel along the back of the neck to avoid damaging the instrument.
Originally, buttons were to replace the fret bars of the bass guitar, and in that way capture input as the user played. Since this, too, had the potential to cause damage to the neck, another method of acquiring data was needed. Since both the strings and the fret bars of the bass guitar were metal, they were ideal for use as a keyboard matrix. This method of data acquisition is used in the final product.
7.0.2 • Problems
Two major problems were encountered by the hardware design team over the development of the AutoTabber hardware. To get the strings and fret bars to act as a keyboard matrix, none of them could have continuity with another. Unfortunately, the strings are held in a metal bridge. To eliminate continuity between these strings and the bridge, and therefore each other, several methods were attempted. First, heat shrink tubing was used over the ends of the strings that made contact with the bridge. However, the tension of the strings caused them to break through the flimsy heat shrink. Next, the ends of the strings were coated in rubber cement. This too, however, was too weak for the pressure of the strings. Many strings were unwound or snapped during this problem phase. A myriad of items were used to finally conquer this problem. Plastic washers stop the metal nut on the end of the string from contacting the bridge, and electrical tape and heat shrink prevent the string from doing the same.
The second major problem for the hardware design team was getting the PIC18F4550 programmed. To program the PIC with the USB bootloader firmware, MPLAB and the MPLAB ICD-2 programmer were selected, as they were the most readily available option. However, when the ICD-2 programmer was available to the design team, they were unable to get MPLAB to recognize the PIC microcontroller. It was eventually determined that the wrong programming circuit was being used by the team member in charge of programming the PIC. With the correct circuit, MPLAB detected the PIC, and the bootloader was able to be programmed.
7.0.3 • Future
There are a few limitations to the hardware that, with more time and resources, could be improved upon. Since the keyboard matrix will only detect one note played at a time, the user of the AutoTabber cannot play chords. For a bass guitar, this is less of a problem, since it is very rare to play chords as a bass guitarist. Also, playing techniques like hammer-on’s, pull-off’s, slides, bends, etc, cannot be detected by the hardware. With more time, a different approach could be taken to overcome this limitation.
Having the components and wiring mounted on the outside of the bass guitar was a limitation made necessary by lack of resources. If the AutoTabber were to become a product produced by a major company, for instance a guitar manufacturer, such a company would have the resources to mount the components and wiring for the AutoTabber inside the guitar. This would be the most ideal location for the AutoTabber hardware. All the user would see would be the USB plug on the end of their guitar, near the standard phono plug.
7.1 • Software
7.1.1 • Design
The programming language that was chosen by the software design team for the AutoTabber software was C# (read as C sharp), for several reasons. First of all, the software design team already had a brief introduction to the C# language. Because C# is a C-based language, the learning curve to use it was not overly steep.
C# has the ability to handle system objects behind the scenes, without the worry of the programmer. Two system objects were used in the AutoTabber software: a system timer, used to keep track of time for the metronome and time stamping, and the serial port system object, which gave the ability to receive data over the serial port without having to worry about any extra handling. Any drawing to the screen is also handled behind the scenes by C#, something that would otherwise be several more lines of code to perform in another language like C++ (read as C plus plus).
C# essentially made programming the software easier, in a sense of less redundant and more compact code.
7.1.2 • Problems
There were several problems that occurred during the programming of the AutoTabber software. The first was the decision of how to display additional notes after the screen was filled up. Initially, it was decided to use a scroll bar and scroll down when more notes needed to be displayed on the screen. This idea didn’t work, since there was no easy way to cause the Music Display Area to dynamically increase vertically when it needed to display more notes.
Added to this first problem was getting the Music Display Area to scroll down as more notes were added, so that the user could see the newest data. Whenever it did scroll down, notes and the lines for the staff/tablature appeared multiple times. Any possible solution to this problem would have required a major overhaul of the display functions, and time was limited. This was overcome instead by having the software display different page numbers – basically, different parts of the music at one time. It was easier to get the software to dynamically create new pages than it was to get it to scroll down properly.
Another problem was synching and setting up the agreed upon byte value so that the software could correctly decode the value the hardware was sending it. Once it was agreed upon by the software and hardware design teams that only one byte would be sent, in ASCII, the software was able to correctly decode the data it was receiving.
The last major problem was splitting notes, and keeping the duration of each bar/measure correct. When the guitarist plays a note, that note’s duration is calculated and it is displayed on the screen. However, this originally lead to having a whole note and a half note in the same bar/measure (for example), which is inaccurate if the time signature is 4/4 (four beats per bar with the quarter note being one beat). To fix this, a function was created to count the duration of each bar. If the counter in the function was greater than a predetermined value (for 4/4 it is 16), it would call another function to split the note. The note splitting function looked to see what the counter was at and what the bar duration would be, and then split the note to fit properly into the bar/measure.
7.1.3 • Future
There were originally a lot more features planned for the software portion of the AutoTabber. However, due to time constraints and setbacks with other problems, these could not be implemented.
One feature that was planned to be implemented was note ties. This would have allowed the guitarist to play a held note longer than one bar measure. A tie would have been added below the two split notes, linking them as one held note. This feature proved to be too difficult to implement with the time remaining for the project, but would be one to add in the future.
Another feature that would be added would allow the guitarist to select an ‘open string’ note, and change which string it belonged to. Since the hardware cannot determine which string was played for an ‘open’ note, the software currently displays the ‘0’ in the tab across all four strings, and a rest on the staff. With this feature, the user would be able to go back and edit the ‘open’ note to appear on the correct string, and the correct note would appear in the staff.
Additionally, editing for notes would have been implemented with more time. Adding playing techniques to notes such as hammer-on’s, pull-off’s, slides, bends, etc, would have been added. Since the hardware cannot determine such playing techniques, this feature would have allowed the guitarist to edit their captured data and add these techniques in.