Wednesday, April 30, 2008

Dissociative Fugue

Part three of deceptively named posts.  I've made a proto-melodic generator in Pure Data, which is kinda neat.

Right now the melodies it generates are random walks between between 90 and 600 Hz with ocassional excursions between 45 and 1200 Hz.  The occasional excursions are a function of doing the limiting based on what the note currently is, rather than what it could be.  Since one of the steps is a full octave up or down, it can bounce out pretty far before it starts getting called back in.  Ultimately that might get revised, however I don't think its terribly important.  The other component is a tempo generator that messes with the master clock for the system, speeding up when the notes are high and slowing down when they are low.  This favors the low end of the spectrum, and adds a bit more interest.  Eventually a full note length and timing module will be implemented, so that there is more freedom in determining individual note length.

 I made a nice little repetition prevention system, but sadly, I don't actually need it now, since I've placed everything relative to the preceding note.  I was using a system that played specific notes and since that system could (and frequently did) play the same note repeatedly in series the repetition limiter was far more important for it.  On the upside, making the detections system has given me some better ideas on using recursion to make the whole thing work.  Recursion and Markov chains...fun times.

I really like the infinite scale idea, but it has some downsides.  First, it is unlikely that anyone could (or would want to) manually play any pieces generated by this method: it just doesn't correlate well to existing musical notation.  Second, since it does break with the traditional notation, making music theory "work" in this context is much more difficult.  I've been having to use journal articles to supplement the theory textbook, which is good but not helpful in a lot of areas right now.

JSTOR, an online database of academic journals has been invaluable in working on this project (and just about any project in the humanities or arts).  Frankly, I'm really glad someone else sat and did a study of the mathematical basis for consonance and dissonance.  Right now my note determinations are from consonant ratios, which makes a pleasing, but very mellow melody.  I found an article on the basis for dissonance, so when I get some free time that help me will add some spice to the mix.

Next, I'm going to clean up the note selection process a bit, and try to add in some way of storing melodies for playback.  I don't really know how I'm going to work that one, as PD doesn't seem cut out to handle generating and reading complex tables.  I've decided that I'm likely wrong, and that I can, I just don't know how to do it yet.  Soon I will.  The melody needs to be stored so that it can be played back in different voices at other points, which is one of the defining characteristics of the fugue.

--
Robert Alverson

m*lambda=d*sine(theta)

Thursday, April 24, 2008

The Sound of Music

Yet another in a series of deceptively named posts (see "VM Wear" for another example).

I've started trying to write a fugue generator, which is only slightly more complicated than actually writing a fugue. I picked fugues because they are a fairly well defined composition, and they are marked by repetition, both of which I thought would make writing this a snap. Oh, how wrong was I.

First, fugues aren't well defined at all. About the only characteristic that people can agree on is the use of repetition, and even then there is still some confusion. Second, having to make a generator that tries to actually sound like an actual existing form of music is a pain, particularly if you try to use existing musical conventions.

Musical conventions are pretty complicated. So far I've dedicated several days to translating music theory into Markov chains and other structures, and still really don't have any product to show for it. However, I have simultaneously leaned a lot about Markov chains and music theory, which is good. Markov chains are pretty straightforward; music theory is a tougher nut.

Music theory is built on centuries of previous generations methods and notation. The notation is interesting, because the existing notations doesn't fit what it is supposed to represent cleanly, or rather it doesn't scale nicely from playing to theory. Chords and interval notation and the rest seem kinda hacked together. When playing with intervals, all sorts of weird things can happen. When you are building chords you end up with a fair number of exceptions and changes. I feel that much of this has to do with using a just intonation rather than a tempered scale. The primary difference between the two is that tempered scales use equal divisions between the notes, and just intonation tries to use the smallest whole number ratio between notes. That being said, I've decided to throw caution to the wind and use a tempered 19 division scale for my generator. (Most music is played in a 12 division scale using just intonation.)

I like this better, because the ratios are relative to any two notes' frequencies, and the consonance/dissonance between the notes can be expressed mathematically. This simplifies writing the progression algorithm, as I could simply base it off of numerical consonance, rather than having to translate music theory into probabilities and conditionals. With basic bounding and checks for repetition, even a random walk should be less dissonant in 19 as compared 12.

The reason that I can chose a 19 tone scale is purely digital, or rather a lack thereof. I don't have to play an instrument in this scale, the computer does. traditionally, instruments have been limited by the number of fingers its operator has. 12 divisions is a good compromise between playability and consonance, whereas 19 would be a bit harder to play.

Stay tuned for further developments, hopefully I'll have a working system shortly.

--
Robert Alverson

m*lambda=d*sine(theta)

Wednesday, April 9, 2008

Comcast, and the Great Internet Shortage of '08

I suppose it's more of a lean season than a traditional internet shortage, as we still have a connection.  It's at the very least a bit faster than when the campus network bought it in the Internet Shortage of 06.  That was twelve hours of no internet, which left us confused and frustrated, forced to leave our rooms in search of entertainment.  On the upside, it lasted only twelve hours.  For a month now, we've been experiencing terrible packet loss in the house, generally over 25%.  This makes the connection painfully slow.  Comcast was routing us through New York for a time which added a few hundred milliseconds to the time required to access any server on the West Coast. 

I called Comcast to see what the deal was.  They say that its a problem with the backbone, and that they just don't know when it will be fixed.  We will get a credit for any downtime when they finally fix the problem, but it don't think we will actually ever see any money.  I think they will say that the network was never down entirely, and that the EULA I signed doesn't guarantee that I will actually get all of the bandwidth I paid for.

I'd switch, but there aren't any comparable services in Santa Cruz.  Although, a guaranteed 3mbit connection would likely be faster than the hypothetical "8mbit" connection that I have now.  I'm just waiting for fiber to get here...I had it back in Sac, and it was the most wonderful connection I've ever used.

So, if anyone has a rockin' connection in Santa Cruz, let me know.  I'm sick of Comcast.

--
Robert Alverson

m*lambda=d*sine(theta)