This week on the project I worked on expanding the pitch generator’s capabilities, and refining the iPhone motion controls. Concerning the pitch generator, it can now generate some predefined chords to play, on top of the pre-existing option to play randomly selected notes. This adds greater variety to the music generated, and gives a performer more flexibility in creating a piece with the object. A user can now also randomly shift the register of the generated notes by flicking the ZigSim iphone to the left.

Speaking of ZigSim, I refined the controls for motion tracking. I was finding that the software would be either under or oversensitive to movement, so the slightest movement in one direction would trigger something, or I wouldn’t get anything at all. As I found, what was happening is the code was treating every single slightest input from the motion as “true”, and pumping it out very quickly. I eventually fixed the issue by adding a stricter true/false evaluation, limiting the how much data was analyzed at once, and measuring gyroscope instead of acceleration data. This fixed the oversensitivity, but I still found the code would note respond to motion in some cases. I learned however, this was because I was actually being too forceful in my movement. The program actually became much more responsive when I moved the phone with less force.

Concerning the project’s graphic generator, I added some variation to how the particles move. Before, the glowing balls would appear at random points on the screen, creating a bubbling effect. Now however, its possible to activate second mode for the graphics where the glowing balls move around the screen randomly, sort of like the classic DVD screensaver. This mode is activated by flicking the phone to the right.

Lastly, Dr. Bob and I are still having difficulty getting the project’s hardware to work. We have tried several different versions of Arduino code, but not seem to work. We have yet to to pin down what the exact issue is, but we are meeting later this week to continue working on it. Once the Arduino code and current reading circuit runs properly, touching the plasma globe will activate music, and the project will be mostly complete!

I am back reporting on the project after a break from blogging. Life and school got busy, and I did not make as much time as I should have to report on the project’s status. Nonetheless, the project’s development is sill in a great spot, albeit with some vexing hardware issues.

As seen below, the project’s hardware component is fully assembled. The plasma globe arrived on February 15th, a few days after my last blog post. How the wiring works is the plasma globe receives power from an adapter cord, and then the current from the plasma globe is wired to the INA219 current reader. The INA219 then transmits that data to the Arduino microcontroller board, which in turn is sent to my laptop via a USB connection.  Assembling the hardware was fun, as we had to split electrical cables and repurpose them, and then use a soldering iron to attach the INA219 to the Arduino.

With my laptop receiving the raw data, we then had to transform it into something usable with Arduino code. Surprisingly, this has been the most challenging and problem filled phase of the project. The code below is the most recent version, created after many hours of me and Dr. Bob experiencing several compilation errors, or the code only running half of what was programmed. As we discovered, the most vexing compilation error was simply because we had duplicates of a library necessary for the project, and this was fixed by deleting one. Many hours were lost over a simple solution.

As for the only half the code running, we suspect this is actually caused by the INA219 I ordered being faulty. We found that the code would sometimes fully function, but only if the INA219 had just the right contact with the Arduino. At one point early in the year, I thought I lost my INA219. It turned out it was just in Dr. Bob’s office, but considering the hardware issues, maybe it would have been better if I had lost it. Nonetheless, we will be using a new INA219 and that should fix the issues. Once the code is fully functional, all that remains with the project is to finish the MaxMSP code and start preparing my Capstone presentation.

Most recently on the project, I added the ability to change between different VSTs. This lets a performance with the plasma globe change between different timbres. Since I had upward punches with a ZigSim phone causing chord changes, I decided that punching forward with the phone should cause the the VST to change, letting a performance be more visually dynamic.

Speaking of which, we also added more control to the generated graphics. Before, the particle graphics would generate with a preset, and be unchanging in how fast the particles would decay and move about. Dr. Bob then had the idea to make the graphics change with the music, beyond aligning with new generated pitches. So we decided to make it so the that faster notes were generated,  the faster that particles would decay, and the freer that individual particles would move.

The results looked like this, with the top image being when the notes generate slowly:

And the bottom image being when notes generate quickly, creating a cool bubbling effect.

Lastly, I began working on the code for measuring the plasma globe’s current. I watched some Arduino video tutorials, and then found a project where someone was creating a voltage meter for their Arduino. Where the code is right now, it would only display the voltage directly in Arduino. This is a useful baseline, which I can modify to read the current, and then transfer to MaxMSP.

In other news, the plasma globe will be arriving soon, and Dr. Bob and I decided it would be better to assemble all the circuitry then, so we would actually have something to test with the Arduino code.

Week 3 of the project mainly focused on giving more flexibility to the pitch generator, but also making the layout more organized. This was done by adding more to what could be triggered by punching upward with a ZigSim phone. Before, punching up would only turn on the video,  but now punching up more changes what pitches are generated.  In the current setup, punching up once turns on the video, punching up a second time changes the pitches generated from being completely random to a specific chord, and punching up a third time or more, changes the chord.

The necessary number data for the chords I generate are stored in a [coll] object, which acts as a number table. Operating similarly to the random pitch generator, this chord generator picks a random number between 1 and 4, and then the corresponding row in the number table outputs the a stored number. So in this case, if the number 1 is randomly selected, the number table while output the zero I have stored in that 1st row, and if 4 is randomly selected it outputs the number 15 stored in the 4th row. If the user decides they want to move to the next chord by punching up, then a 4 is added to every randomly generated number, thus changing the range of numbers from 1-4 to instead 5-8.

As an interesting side-note to add, I mentioned in last week’s post the pitch generator would sometimes not generate silent pitches, and I explained this was being caused because some notes would be generated with volume/velocity of zero. As it turns out, this was only partly true. While keeping the randomly generated velocity number above high enough was necessary, when Dr. Bob and I tested the patch, it turned out some pitches would still be silent. We discovered this issue was occurring because the VST I was using has a very slow decay, and so would run out of available voices for new notes. Our solution was to change the VST used and this fixed the issue. In future however, I would like use both the old and the new VST, as I liked the timbre of the old one.

Over next week, I will add more chords that can generated to the number table, and began working on putting together the hardware components for the plasma globe input reader. As of today, the plasma globe will ship in a little over a week!

In week 2 of the project, I refined the random MIDI note generator, the projected graphics, and added more specific controls with the ZigSim data. Starting with the MIDI note generator, I was noticing that sometimes a note would trigger, but there would be no sound. While initially confused, I realized this was because of the [random] object. Since it generates numbers between zero and a specified number, this would naturally cause some of the MIDI notes to have velocity/volume of zero.

To counteract this, I made it so every generated random number would have 31 added to it. This would still allow for various volume levels of the pitches, but prevent some from being completely silent.

 

For the projected graphics, an issue I was experiencing was that they would still be visible, even if there were no new pitches generated.

To fix this, I took and scaled data from the audio gain meter, and then had it affect the graphics’ bloom level in the graphics generator subpatch. This resulted in the graphics becoming brighter the louder the audio on the gain meter, and decaying to black if there was no audio at all.

However, this issue isn’t necessarily a problem when I think about it. In the coming weeks, I could potentially refine bloom level controls, letting the user control how quickly the graphics decay, or even associate levels of reverb with the graphics, so that the muddier the audio becomes, the slower the graphics decay, gradually filling up the screen.

Then, the ZigSim controls. As suggested by Dr. Bob, I added [gate] object so that acceleration data would only come through if the arm was at a certain angle. This then allowed me to have a punching-up motion activate the graphics, with no graphics being generated from MIDI data until the user has punched at least once. In later versions of the project, punching up will cause timbre changes, or perhaps alterations to the projected graphics. For the rest of the ZigSim controls, I made it so twisting the wrist changes the duration of individual notes, while moving your arm further from the body increases the tempo of the metro. Properly scaling the ZigSim data also took some effort, as the range of comfortable motion I had was less than what was needed for the [slider] objects, which ranged from 100 to 2000.

Lastly, I had to tweak the acceleration data. Since ZigSim generates precise data very quickly, I was finding it would constantly send out bangs, causing the video to activate without even punching up. I fixed this by limiting the number of bangs that could pass through to 1 every second.

Next week, I will program the patch to allow the user to randomly generate notes from more precise pitch collections, and let them alter timbres and the graphics.

 

The first week of work on the project involved ordering all the hardware components, and creating the basic Max code. Besides the plasma globe, the main feature of the project, the other hardware required for this project included a INA219 current reader, an AC adapter, and an Arduino UNO R3 microcontroller board. The total cost of the components was relatively inexpensive as technology can go, coming to around $80. Everything was ordered online, however I was able to quickly pickup the INA219 from a local store. As of January 24th, everything has arrived except the plasma globe itself, which should ship February 9th.

The rest of the week was spent coding the project’s basic Max framework. With Dr. Bob’s help, we created the subpatch that will take incoming acceleration and quaternion data from an iPhone with the ZigSim app. This part of the coding will allow the user to alter aspects of the sound and visuals by moving their arms.

In the main patch I assembled, I used the [metro] and [random] objects to generate MIDI notes with random pitches and velocities at constant speed. The MIDI messages were then routed into a [vst] object so the timbre would be more interesting. For the projected graphics, I downloaded the PartyLights Jitter recipe from the Cycling 74 website as I felt they best reflected the fantasy element of the plasma globe I’m trying to capture. To make the graphics responsive, I made it so each new MIDI note would cause the graphics to change their position on the screen.

In future weeks, I will add more possible motion controls for the audio and be more specific with the pitches that are randomly selected.