More Digital History!

Only a little more than 24 hours to go until our class’ digital exhibit presentations and things are going well sine the last time I checked in. I’ve managed to successfully build all three sections that I discussed in my previous post, resulting in a project that is almost complete. That is not to say, however, that there haven’t been a few hurdles along the way. Working with any kind of technology that is completely new to any student is bound to cause some frustration, and goodness knows I’ve had my fair share already.

One of my first issues was figuring out how to get MIDI files to play correctly on Max. The aforementioned program has a number of objects that are designed to play MIDI files. What I didn’t realize at the time (technological dinosaur that I am) was that there are several different types of MIDI files, and that it is very difficult to figure out which kind you have until you try it out with the various Max objects meant to play them. After I’d figured out the difference between Track 0 and Track 1 MIDI files, the actual process of making the file play was pretty straightforward.

Probably the most difficult part of the build was figuring out how to smooth out the accelerometer data in such a way that the information passed to the rest of the programming would be consistent and replicable. Before I even made it to dealing with the accelerometer I had already experienced problems with my BPM controller running far too quickly. Needless to say, most people can’t conduct a song at 500bpm without their arms flying off in the process (or something close to it). In order to try and slow down the speed of the music, I decided to only use the Z axis on the accelerometer to deliver a bang to the BPM meter, as opposed to having the accelerometer deliver a bang anytime it was moved in all four directions. This decision also served to keep the programming a bit less messy, which is always a good idea when dealing with coding. After I had shaped a multislider in such a way that it would deliver consistent data, I connected a simple Boolean statement to the Z axis of the accelerometer. This statement ensures that if the accelerometer makes a down stroke then a one appears on a number object. At all other times, however, the same number object is told to read zero in order to slow down the BPM meter.

Although I still have a couple bugs to sort out, most notably the manner in which the accelerometer will be connected to a switch for the BPM meter, I’m confident that things will be in working order by Wednesday. Check back in a couple days for the finished product!