Hours: 8

Now, however, I’m trying to get onto SL to finish what I wanted to finish yesterday, but I’m not having much success.  The wired network is working, but, as usual, is not fast enough to actually log in to Second Life on.  The wireless network, which is what I usually use because a lot fewer people are on it, seems to be nonexistent still.  For the moment I’ve hit a wall.  I’ll try again throughout the night, and keep trying over the course of the week when I get opportunities.

Time worked: 4 hrs.

I wish I had a little more time to work on the project here in the home stretch, but lately that’s been easier said than done. Well, we’ll see what happens.

Time so far: 1 hr.

EDIT: Worked on some code, replacing the stuff that I lost.  The network isn’t being especially friendly to Second Life right now, so I’ve got the code in Notepad and will just copy-and-paste it.  I’ll upload things in the next day or so sometime when the network isn’t as active.

Updated time: 3.5 hrs.

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.

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.

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)

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

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.

Meantime, these YouTube videos are a demonstration of the visualization which I will be attempting to replicate:

I’ve had a little trouble getting these videos to come up tonight, but hopefully that’s just a temporary YouTube or network issue.  Let me know if you can’t see them and I’ll try to work it out.

Approx. Hours: 2-ish