First of all…

I would like a couple of quick updates made to the Space Fight module

1. With further play testing it's become apparent that ships speeding up when they get more aggressive isn't actually a good thing for them. As it is, they always catch up to their targets too quickly and then get stuck on the side of them, spinning in circles, and not able to shoot them. So either
   • (probably more desirable) whenever a ship gets too close to or touches its target, it should disengage hunting behavior or find a new target
   • or speed could not be affected at all by aggressiveness.
2. I've tried all sorts of normalization on my end in Max and I'm still not reliably able to get the lengths of the players' bars to be on par with those of the enemies'. This always seems to result in a game that's just not fair, as one side can always score more easily than the other. I've come to the conclusion that it's the sort of thing that doesn't seem to be predictable automatically, so I would just like to have 2 new options added to the Space Fight visuals menu that allow for manual adjustment of a multiplication factor for each team. That way it can always be fine-tuned as necessary. The options on the menu would look like
   • [gain] applied to player EQ
   • [gain] applied to enemy EQ
   • There would be no units on the UI, just the slider over the word gain, although the range of the parameters could go from the EQ numbers being halved as they enter Unity (on the far left of the slider) to the numbers being doubled (on the far right), with no change in the very center of the slider (this might need some playtesting). Suitably-sized increments would be needed to allow for fine-tuning.
   • The EQ numbers would need to have the multiplication factor applied as they enter Unity. Also, I would like to impose a hard limit on the results, at something like .99 or whatever can prevent a full-length bar from triggering overlap with an opposing bar that's at 0. As it is, if a bar reaches all the way across it seems like it always triggers an overlap, even if there was not actually an opposing bar there.
   • Then I would just like to confirm that clicking "restore defaults" on the Space Fight menu returns these 2 options to default (no multiplication).
3. I would like each song in my main app to function as a new game in the Space Fight mode, so when the time is right I will send a /amanuensis/fresh message, at which point all of the ships should be removed, the score should be reset and the game started over.
4. I would like the game to be able to accept EQ data from a backing track and handle it in a unique way. I will send the EQ data in the same format as the other sources, except that it will have a 0 in place of the source/track number. I would like the backing track to essentially "fight itself" and to do so the EQ data should be duplicated as soon as it enters Unity and the duplicate list of numbers should be reversed. Then these 2 mirrored lists can each be displayed as EQ bars on one side of the battlefield, one on the player's side and one on the opposing side. They can be some neutral color like white/gray.
5. Aggression should be calculated based on the average length of all of the nonzero bars present at any given time.

And also another option added to the instruments menu with 2 selectables in it (and therefore appearing on 2 lines)

randomize pitches after [no amount-99 seconds] of disuse
on [all instruments/the most recently played instrument]

1. [no amount-99 seconds]
   • The 1st selectable should be a slider ranging from 0 to 99, with increments of 1. At 0, the text should display "no amount" and every number greater than that should display "X seconds".
   • In the same manner as most of the other menu options, it should send and receive its values through the /amanuensis/menu/scramble_after i OSC message, where i is the integer 0 to 99.
   • Also in the same manner as previously, it should request the value from the main app (whenever the menu opens, was it?) with /amanuensis/menu/scramble_after/get.
2. [all instruments/the most recently played instrument]
   • The 2nd selectable should have 2 possible options, "all instruments" and "the most recently played instrument".
   • In the same manner as most of the other menu options, it should send and receive its values through the /amanuensis/menu/scramble_all i OSC message, where i is 0 for "the most recently played instrument" and 1 for "all instruments".
   • Also in the same manner as previously, it should request the value from the main app (whenever the menu opens, was it?) with /amanuensis/menu/scramble_all/get.

Then…

We can decide what an appropriate payment would be for everything up to this point, but if it's all right with you I would like to pay with a single total at the end, just because PayPal charges something like a $5 flat fee so I'd like to avoid making extra small payments if possible.

Items 3 and 4 from the following 4-point list (the line graph and the background colorization, not the bar graphs) are actually the most important, so I would like those to be done first.

The main task of this update would be in adding some real-time analysis visuals to the main game. I think I've decided I would like them to be in the form of the sort of "ticker" that scrolls from right to left across the top of the screen (to the right of and ending at the scoreboard). This ticker could be quite fat actually, as thick as needs be to display the information legibly. It would consist of some overlapping bar graphs as well as a line graph for each source. More specifically, for each track (pair of sources, positive and negative) there would be

1. one larger bar graph in the background of that lane of the ticker
2. semitransparent on top of that bar graph there would be 2 more, half the size and one for each source
3. a line graph on top of those, taking up the full lane, with 2 lines on it, one for each source
4. background colorization behind it all, switching colors at certain points based on which source's line is on top during that span

OSC messages will arrive to deliver the data that should be displayed in these graphs. They will be in the formats

1. /amanuensis/ticker/groove i f f where i is the track, the 1st f is the X-coordinate and the 2nd f is the Y-coordinate
2. /amanuensis/ticker/transients i f f where i is the source, the 1st f is the X-coordinate and the 2nd f is the Y-coordinate
3. /amanuensis/ticker/rating i f f where i is the source, the 1st f is the X-coordinate and the 2nd f is the Y-coordinate

The x-coordinates will actually be millisecond values reflecting the amount of time that passed since the Max app was started, meaning every new message will have a higher X value than the last. The largest received X value can be graphed at the far right of the screen, with all the rest streaming out behind them to the left. Only as many of the oldest need to be graphed as will fit across the screen. This should create the scrolling marquee sort of effect I'm looking for. If any messages arrive out of order, they can still also be graphed properly simply by using their X values.

I would like the system to be able to handle any arbitrary range of Y values that are sent, although I plan to have them normalized 0-1. But in any case, the range of the graph vertically should automatically scale to have the highest Y value yet seen (by any graph) be at the very top. All of the graphs should always use this same scaling so they will all be in consistent proportions with each other.

1. messages will arrive in a constant stream, most likely every 30 or 40 ms
2. messages will arrive in a constant stream, most likely every 30 or 40 ms
3. messages will only arrive intermittently; these will be the points to graph, with the lines of the graph connecting them

In the end, the colors, shading, transparency, etc. of the ticker just need to look good and be legible, but in general

1. the bars on this graph should be monochrome in color, possibly some shade of gray
2. the bars on these 2 graphs should be semitransparent to see those below and in colors representative of their sources
3. the points and lines on this graph should be solid and in colors representative of their sources
4. in the very background of the ticker solid panels of color should alternate based on whichever line graph most recently received a higher value (you don't need to do any math to figure out where lines are crossing; I want these panels to transition in color only at the points in the line graph)
   so

---

There is no particular deadline as long as we stay in constant communication about the progress of the project.

All code will need to be clean, organized and very well-commented. Please contact me if you have any questions or would like clarification about anything! If you see a better way to do something than what I'm suggesting, please bring it up!