The Week of April Fools’ March 31, 2008
Posted by bperdue in : Uncategorized , add a commentOkay, so I haven’t actually gotten anything done since I posted last Wednesday, but the project is my only assignment to work on for the next few days, so I plan to spend at least 3 hours on the project by meeting time. Tomorrow (probably for roughly half my work time) I’ll focus on the survey, and Wednesday I’ll do my best to wrap up the visualization code.
EDIT: So here are my thoughts on testing the visualization. Assuming a short survey, it seems to me that the most useful technique for this visualization as it stands would be to run the visualization for a piece of music (perhaps without the music) and then have (is possible) several MIDI files as choices for what piece the visualization was representing. Further, we could ask relevant questions like:
Does the visualization tell you anything about this piece that you hadn’t noticed before?
Do you feel that you could learn more about a piece of music using this visualization?
Which pitch (note) would you say occurred most often during this piece of music? Least often?
Further, we might ask the testers to describe the “action” of the music - what happens, what sort of patterns it follows, etc. Also, it might be interesting to have two pieces ready for visualization and ask if the testers can see the difference between the two, and if so, describe it. It would also be a good idea, I think, to get a general idea of how much music-related experience a user has; that is, has the user ever played an instrument, taken a course in music theory, and so on.
In browsing around the internet I found lots of visualizations of various sorts with papers and plenty of details, but none of them (that I looked at, anyway - I found tons of sites and didn’t have time to browse through everything thoroughly) stated explicitly what they did for testing (if anything). For the moment I’m thinking of going with the above approach, but I am, of course, open to any suggestions that anyone might have about what can be asked about the music visualization.
Approx. time: 1.25 hrs, more tomorrow
EDIT 2: Okay, so I was a little sidetracked by an unexpected project, but I still made progress on coding this afternoon. The visualization is (well, was) all set and ready to run when I discovered that most of the code I wrote last week was missing. I’ve searched through my inventory and cannot locate the code. I assume I’ll just have to rewrite it, which is fortunately only a minor setback; most of the time I spent on it was in design, and since I still remember that part I should be able to re-implement the code in no more than an hour. I don’t have a free hour between now and the meeting, so the code won’t actually be done, but the visualization should be good to go in short order.
Appox. time: 3 hrs.
One Week in March March 24, 2008
Posted by bperdue in : Uncategorized , add a commentOkay, so once again I haven’t made a lot of progress since the Wednesday meeting. Lately it seems like my work time on the project has shifted from Sunday/Monday to Tuesday/Wednesday. That being said, I expect to have more to show by the time we have the meeting.
For now, I’ve been toying with the visualization code in Second Life and perusing the thesis which created this visualization in the first place (I found a PDF of it online). I feel like I’ve got a better handle on what I’m looking at now. The last major coding thing to do - and this is more tedious than difficult - is to get the tracer all set to go to the appropriate location in the visualization for each of the twelve pitches it may get out of an MIDI. Eight of them are pretty obvious, and the other ones I just need to plot. I’m debating whether I should hard-code the locations (i.e. in a switch or if) or have the tracer calculate it based upon sensor data (which would facilitate moving the visualization). The latter is the more appropriate option in terms of style, but it would increase runtime in what I would call a relatively time-sensitive code block.
More later…
Approx. time worked: 1.5 hrs thus far.
EDIT: I’ve spent a couple of hours working on code (when I could; the connection was a bit erratic). I’ve yet to actually test run the code, unfortunately, because I’ve been fine-tuning certain bits to run better, especially the older stuff I coded solely to test the motion of the tracer back during Spring Break. I’m nearly ready to go, though; just a few more tweaks and I won’t have to wonder anymore about how horrible the crash will be when I actually try to feed the program a CSV file!
Updated time worked (total this week): 3.5 hrs.
This Week Part 2 March 19, 2008
Posted by bperdue in : Uncategorized , add a commentI’ve spent several more hours working on getting the visualization to interface with a file. Unfortunately, some of that time was spent trying to get the MIDI to CSV converter to work - unsuccessfully. For some reason, every time I try to run it on an MIDI file, the converter crashes. Needless to say, this doesn’t produce a file I can use.
For the time being, I’ve started writing the LSL code to read CSV-formatted data out of a notecard and communicate that to the visualization. I’ve got the bulk of the code written, though I’m still working on debugging and some secondary functions. I also have yet to update the code in the visualization’s tracer. Worst-case scenario, I can make a mock-up CSV file that will still prove the visualization’s functionality with such files.
Approx. hrs: 4 (5 total this week)
This Week March 17, 2008
Posted by bperdue in : Uncategorized , add a commentI haven’t had a lot of time to work on my project the past week, but I’ve made some conceptual progress and I should be able to put in some hours between now and Wednesday’s meeting.
As noted last week, my latest obstacle is the fact that getting the visualization to “listen” to an MIDI doesn’t seem to be possible. This can probably be worked around by using a converter which will put an MIDI file into Comma-Separated Value (CSV) format, and then using that file (which is text and has a standard format) to get the information I need. I’m still working on precisely what to do with that ability by exploring the LSLWiki. My best guess at the moment is that I’ll have to make the MIDI files into notecards and then use the llGetNotecardLine function. I can store the notecards in a separate prim so that the visualization can always find them, I suppose.
Fortunately, MIDI will make much of my job otherwise fairly simple. MIDI assigns numeric values (from 0 to 127) to notes over 10 octaves; I’ve found a table which matches notes to numbers. Extracting these values from the CSV file should be mostly a search problem, which might take a little coding but shouldn’t overall be abundantly difficult. Then I can have some sort of conditional - do switch statements exist in LSL? - to make the tracer prim fly around a bit.
Another thing that may be possible is getting the visualization to work in time with the related MIDI. The CSV holds time values for each event in a file, including notes, in clocks. Using that data and LSL’s time functions (which are in seconds), I may be able to get the visualization to run in time with the MIDI. Alternately, if the visualization processes quickly enough, I may just be able to have it change when the notes change, which would certainly save a lot of code but would rely on code efficiency to a greater degree.
Approx. hrs: 1 so far, more to come
The Week After Spring Break March 10, 2008
Posted by bperdue in : Uncategorized , add a commentOver the course of Spring Break I finished the structural aspects of the visualization, as well as much of the scripting for the visualization. Here’s some screenshots:
As you can see, the “tracer prim” in the middle zips around inside the spiral array. Points on the spiral array (specifically the spherical prims) represent different keys, and the tracer heads to the appropriate spot according to what’s going on in the music. As it goes, it leaves a trail of green particles which I’ve set up to make a line.
There are a couple of current issues with the visualization. A minor one is that Second Life’s particle system only allows the particles to exist for 30 seconds tops. In the original MuSA.RT visualization, the tracer’s path remains the entire time. As long as you are watching the visualization I suppose it isn’t a huge deal, but that is one difference that SL’s limitations necessitate.
A more serious issue at the moment is that there is no way (at least using LSL) to allow the visualization to listen to an audio file, like an MIDI. That’ll be the main hurdle to work around from this point; there should be a way to do it using some outside software to get the data somehow, but I haven’t tried anything just yet.
Other than that, a few more scripting classes (NCI’s Scripting 5, I think?) and a little research on MIDI’s rounds out the overall work I did since last week.
Approx. 7 hours.