Wake up, brain. Something about music and notes.

Okay, I remember now. Not complicated at all, I already have it written down somewhere what the gist of the algorithm is. I just don't know how I'll want to interface it.

Probably command line.

Yes! That's simple. The program will be called "nextnote", and you can provide an arbitrary number of arguments which are all notes. They can be given as lower or upper case letters, have sharps or flats, or be given as midi notes.

So you could type this:

nextnote c d e f#

And it would spit out this:

g#

Problem is, though, that doesn't lend itself to building upward to something that will work with chords. I sort of wish there were a simpler way of making a function that could take arbitrary amounts of data for its parameters; I suppose the best thing would be for it to take a string, and then do a stringstream into a vector in the function.

Back in a bit.

Wow. I actually did the thing I was talking about in my last entry and it actually worked.

Anyway, this next entry is just going to be an out-loud brainstorm about what I think will be a very costly method. I should probably develop this idea with the assumption that I won't be working with very large images, or that this is really more for a computer with far more RAM than I have.

The idea is to represent a bitmap as a collection of grains, like grains of sand (blah blah something about the days of our lives). By this I mean if a given pixel has a brightness value of 100, then 100 individual "grain" variables will be added to a resisable array (vector) and each of those 100 grains will hold its own coordinates as a value.

So for a bitmap with N pixels, you could have as many as (256 * N) grains! Furthermore, the whole point of doing this is to morph from one bitmap to another by moving the grains, so you would have at least two images loading into RAM as collections of grains. Then on top of that you would need a way to determine which grains in image 1 corresponded with which grains in image 2. I know how I would do that for 1 dimension, but not sure for 2 dimensions.

Another, less "expensive" idea is to make each pixel one grain and then try to correlate each pixel in image 1 to a pixel in image 2 based on brightness, then keep swapping the pixels until all have moved to their destination.

I'll keep thinkin' ...

It occurs to me now, that for each degree you want to test, you have to offset the flipped image by two degrees. It's hard to explain exactly why, but think of a mirror rotating around an axis; the reflection in the mirror will be rotating twice as fast. If you turn the mirror 45 degrees, everything in it will appear to turn 90 degrees, and so on. So the "flowtest" bitmap need only be 180 pixels wide, and for each column x you need to grab from 2*x degrees around the original picture.

PROCEDURE FOR "FLOW MAPPING"

Assuming you already have a bitmap object to "map the flow" of ...

Establish a radius (how far around each point you want to use), and decide how many inbetween circles you want to test.

    int radius = 10;
    int subpixels = 3;

Make a new bitmap object:

    flowtest = new bitmap(360, radius*subpixels);

Make sure that testx and testy are at *least* radius pixels away from any edge of the original picture.

Fill "flowtest" by grabbing from the original picture such that the direction away from (testx,testy) is x, and the distance away from (testx, testy) is (y+1)/subpixels. Also, dim to black as you reach further out, since we wish to gradually lessen the impact as we move further from the test point:

    value = (1.0 - float(y)/float(radius*subpixels))*value;

Make a score card:

    long int score[180];

Testing each degree will involve comparing the "flowtest" image with itself using a horizontal flip and a series of horizontal offsets. I'm very unsure of the correctness of the following pseudo-code; I know that testing 0 degrees should yield the same results as testing 180 degrees, but when I try to demonstrate this to myself with my hands, it doesn't work visually. Furthermore, what this really tests for is mirroring rather than flow (the assumption being that if there is flow, it is perpendicular to any mirroring). Here's what I have for now, correct or not:

For each degree D (0 thru 179),
    initialize score[D] to zero
    for each column C (0 thru 359) on flowtest,
        CH is column ((360 - C) + D)%360
        for each pixel in C and CH,
            score[D] += (abs(r1-r2) + abs(g1-g2) + abs(b1-b2));

It's important to note that, like in golf, lower scores are better. The score which is the lowest is officially the direction of "flow" for (testx, testy). However you still need another value representing the significance of that, since some areas have more of a sense of direction than others.

    long int relevance = 0;

For each degree D (0 thru 179),
    relevance += (score[degree] - score[winningdegree])

Unfortunately there will be no way to know what this "relevance" value means without comparing it to the "relevance" at several other locations in the picture. After that point you can determine a range, and rescale all the "relevance" values to a nice, neat 0-255. In the interim, you may need an array of long ints or even floats to hold the unscaled values. I don't know how big these numbers will get.

Probably a good way to display it graphically would be to use flow direction and flow relevance as hue and saturation values, with brightness at a constant 255. This way, the areas with more flow will show up as colored areas on a white background (you will probably want to rescale direction from 180 degrees to 255 "pseudo-degrees" so that as things curve, they change hue continuously).