Played around with TarsosDSP library after getting back from X-mas eve dinner with family. Rewrote some of the base classes from the synth example to be non-blocking and let me mutate state (the functional programmer in me is saddened by this. Might think about a Kotlin Actor model for the music synthesis of it gets tooo messy). Realized a cool "game flow" for this project:
- You go to a planet.
- Associated with game entities (wind, rain, bunnies, etc) are a tuple of visuals and sound.
- Visuals are made up of patterns on sprites; Sound is made up of a sequence of Tarsos AudioProcessor chains with some params.
- You wait around and at some point sample the sounds playing at a particular time (pokemon snap but for music haha)
- You take the sample back, do some alchemy on it
- put it in an instrument
- an instrument has at least the properties of turning the sample on and off, and then building one up lets you control parameters (real time modulation) or mutate AudioProcessor and visual objects (before hand modulation)
- Then you can use the instrument in songs.
Sidenote: I am definitely drafting a declarative markup for describing these worlds, and making that the "source" of the sample snaps. That way I can push anything I want server side and store it easily, knowing that the java game implementation is literally just an interpretter and not holding any logic against me. I can see these AudioProcessor object chains getting out of hand really fast!