week 6: program a board!

week 4, part 2.

it's time to live code ;)

This week, I plan to use the board I made from week 4 to test the HID library. HID stands for Human Interface Device. It is a library that turns your circuit into a controller-- like a keyboard and/or mouse. I want my final project device to interact with the code box on Gibber, an online musical live coding environment. I plan to use the buttons on the week 4 circuit board to do some basic testing, just to see what is actually possible with the library.

I programmed the board using the TA tutorial from this site and my programmer board, before it broke.

When I first tried uploading a test program, the Arduino IDE terminated the process, saying that I had to declare the type of device the output board was becoming. In the error notes it said that I could, for example, open Tools -> USB Config and set the USB Config value to HID_ONLY.

I tried this basic program first:
This program just prints "Hello World" to wherever the cursor is. In the video I have Notepad open and every time the board prints "Hello World" at the cursor location I press enter. I tested the program in the Gibber environment and its non-stop printing caused Chrome to crash multiple times. I went back to change the delay between printing and/or tie printing to button presses to stop this from happening and realized that the Arduino IDE was unable to recognize my board as a writeable device.

I realized that this was probably because I had set the USB Config value to HID_ONLY... I should have read into that more. I later realized that I could reset the board by repeatedly pressing the reset button.

I was kind of surprised that worked at all but I'll take it.

After reading through the USB Config options, I set it to CDC_HID so the board could be an HID device while also being writeable via the Arduino IDE.

I wrote some additional functions in my test code while thinking about how my device should interact with the code box. The code is just a controller and can not read the Gibber code box, so I probably would not be able to do positioning based on finding keywords already in the code box. The order of Gibber code on the page does not matter. What does matter is the order of code execution. This meant that as long as I could find a blank line, I could use my device to paste and execute code. The user would just have to be somewhat vigilant-- making sure that variables used by the device have already been declared/previously. Regardless, Gibber does its best to ignore code errors, letting you know something is wrong in the site inspect panel. With these ideas in mind, I test the board in the Gibber environment, trying to simulate how the device might change the code box during a live-coding session:

I have the program using the page down command to jump to the bottom of the page, the enter command to create a new line, and the home command to jump to the start of the line in case the cursor isn't there already. These commands ensure that the cursor is now at a blank line no matter what is on the page, or where the cursor was when the command was executed. I have the program paste "Hello World" so I can see its location. In the video, you can see how I marked a section at the bottom for the device code. I felt that having the device interact with code the user has written would be confusing, and error-prone given that a user that is actively live coding could change these lines around and/or delete them completely. I imagine that in an actual live coding scenario, it would be most convenient for all the variable definitions and user code would be at the top while all of the modification code (ex. chord changes, filter changes) from the device would be at the bottom. In the future, it will be worth testing having the device print lines at the top of the page rather than the bottom, in case the device wants to edit a line it has already printed. If it prints at the top of the page, these lines would always be in the same place, not being moved down by each additional line of code. My only worry here would be that there would possibly be execution order issues. For example, if Gibber crashes (which it does), usually you just re-execute the entire page. If all the modification code is at the top, before the variable declaration code, nothing will execute. Conversely, if we keep the modification code at the bottom, we can add code that keeps track of what was printed where in relation to the bottom of the page.

Now to test the above ideas on a page with actively running live code. I opened one of the tutorial samples and executed the Gibber code in the sample. I also added new functions to my device code. Before, I just pasted "Hello World" into the code box, but now it is time to paste real Gibber code and to also execute it (using ctrl-enter). I decided to run a test where the board would change the reference scale degree of the running sound when either button is pressed. I kept the function that brings the cursor to the bottom of the screen, but this time it prints a redefinition statement for Gibber's Theory library: Theory.degree = 'ii'. The roman numerals in this statement define which scale degree above the root note should become the new reference note, while remaining in the original key. Doing this multiple times creates a chord progression.



In the video, upon pressing the button tied to pin 6, I have the program jump to the bottom and paste Theory.degree = 'ii'. To demonstrate what replacing a line might look like, given the correct placement of the cursor, I press the button connected to pin 7 select the line, delete it, and then print Theory.degree = 'iv'. You can hear how the chord changes in the video! Note that Gibber does not execute changes immediately. It waits for the current 4-beat loop to finish and then executes on beat 1 of the next loop.

These tests give me a lot of hope for the functionality of the final device! For the coming weeks, I will look into designing natural sensor interfaces that will aid live coders during their performances!