Suppose you have a period of time, call it interval, during which multiple data entries are input. These data entries are key press events (key down, key up or key held down). This data is timestamped with time elapsed from beginning of the interval (the first input begins the first interval)
Same data may be entered repeatedly but the elapsed time from the first interval beginning/input may not be exactly the same as on last input. If the timestamps were within certain time distance from the previous input of same/matching key events, then the algorithm will recognize that same input was repeated and this forms the length of the interval. (I'm not sure if this is the best way to do this though)
After the interval ends, a new interval of same length begins. On this and subsequent intervals the data is repeated so that what you essentially have is an echo of the data entries in the "buffer", but only if each data was first entered twice in close time proximity like described above. (This echoed buffer should be time offsettable by +-t milliseconds and any data in the end of the interval moved by this offsetting should be in the beginning of the interval or similarly in the opposite case)
Now the more interesting part: if new data is input while old data is being echoed/repeated, if the timestamp of the new data is near (in time elapsed from interval begin) the timestamp of existing data, then replace that data and timestamp and avoid repeating it. (This needs to also account for the offsetting so that data input during the last millisecond of the interval can replace the currently offset data.)
In addition, the data entries that have timestamps close to each other form "chords" which need to be recognized.
Can you guess what this is for and if so, any thoughts on what else needs to be thought about that I missed and errors in the logic? I've been putting off implementing this project for a year now since the algorithm seems quite complex to me as I haven't done such thing before and I'm still not sure if I'm missing some "obvious" issues.
Polyphonic rhythm sequencer game?
Here's how I would approach a design:
1. Apply the Principle of Seperation of Concerns, don't forget this, no interdependencies. Also you can discover the best design by writing unit tests first, and you should do this everytime, imho.
Perhaps: A class to capture input. A class that examines the input and acts upon it to create 'interval' records or that examines the 'interval' records state and redirects to an appropriate algorithm. Finally, a bare-bones class for interval records - very simple, just the data, easy to serialize...
Design Patterns to consider: Visitor, Strategy, Builder/Factory. It takes some time to find the best.
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.