First off, a couple of hopefully small updates:
- A new OSC message,
/amanuensis/message s
where the argument is a string to be displayed along the very bottom of the screen in the same font (white, size 16) as the scoreboard, potentially extending all the way to the right edge. - Add an OSC sender which can communicate messages back to the main app on port 9091. Use a new OSC message,
/amanuensis/key i
to relay all the user's keystrokes back to the main app. The argument can be the ASCII code or whatever is most convenient. - If necessary, dynamically zoom the camera in and out to perfectly frame the objects on-screen.
Aside from that, this task would involve nothing other than affecting the location spawning targets appear on screen. The idea would be to create a more intelligent algorithm which places them in the most visually informational formations possible, rather than at random.
I would like this upgrade to be embodied in a new class of target. This new class could be called orderedTarget, while the old one is changed to randomTarget. I would like both target classes to still exist, so that either can easily be spawned on command. So for example, there could be a "visualization mode" hotkey that causes the targets to start spawning randomly again, or toggles back to ordered spawning. In the future, this sort of organization could facilitate the possibility of all-new classes of targets, maybe looking or behaving nothing like the current ones, spawning in the mix. I see that currently the random locations of the targets are given to them in TargetManager.cs. Perhaps this as well as the new ordered algorithm could be contained entirely within the new target classes? Obviously you have a better idea of how the code works, so let's discuss a strategy here.
The New orderedTarget Algorithm
I would like to targets to spawn in a spiral, starting in the very center of the screen and working their way outwards, occasionally collapsing back in.
– Every time targets spawn, they will appear in a line along the spiral, with those of the longest interval farthest out and the shortest interval at the beginning.
r=θ
– The exact distance they spawn along the spiral will need to be a direct correlation with the size of their interval. So there will need to be an appropriate pixel-per-ms ratio* determined. So for example, if the ratio was 10 ms per pixel, then a target with interval of 500 ms would appear 50 pixels along the spiral.
– When the first /played message comes in, its timestamp should be used to establish an originTime variable from which all the future spawning distances can be measured. The targets' intervals can continue to be determined in the same way as always, but in determining their distance from the origin they will also need to have their timestamp measured against originTime and have that added to their interval. So distance = (timestamp - originTime) + interval (then converted to pixels).
– Periodically originTime should be reset to the timestamp of the most recent /played message, so the targets don't continue spawning farther out forever, but start over at the origin. I'm not sure exactly when this should happen; it could be after a set amount of time, a set distance along the spiral or maybe whenever a certain message, like /rating, comes in. I'd like to keep this open to experimentation.
– Targets from all tracks can appear along the same spiral, but there should be some lateral variance based on their track so they're not directly on top of each other. There could be a spread variable* which would be a small distance perpendicular to the trajectory along the spiral, which could be applied per track, giving them each their own "lane" to spawn targets in.
– Since there are 32 possible tracks, it would be impractical to give them each their own lane regardless of whether they have any targets on-screen or not. Therefore, the number of active tracks (having targets on-screen or about to be placed) will need to be assessed dynamically. Perhaps the most efficient way would be to increment a count per track whenever a target is placed and decrement the count when removed.
– Targets from positive tracks should always appear in the lane next to (let's say to the right of) their negative counterparts.
– So to give an example: if spread = 10 and there were 5 active tracks (1, 2, 3, -3, 4), track 1 could have its targets appear 20 pixels to the left of the spiral, track 2 10 pixels to the left, track -3 directly on, track 3 10 pixels to the right and track 4 20 pixels to the right.
– I figure spread will be a relatively small number and targets will still overlap all the time. If it's not already the case, targets from negative tracks should always appear in front of those from positive ones.
*This would be a good new adjustable parameter.