So far a proof of concept - MIDI files can be loaded from disk and played back with the associated Player class. Current concerns:
Is the API reasonable? It doesn't conform to the existing ECS style of digital audio playback - but then that doesn't make much sense. MIDI files can't really be panned spatially, aren't really suitable for sound effects anyway, and aren't played back through the same hardware (OK it may be the same soundcard, but conceptually it's a different audio route. This also leads to -
The volume cannot be dynamically adjusted. Neither can it be mixed (reasonably) with the digital audio playback, or hooked by the ImGUI audio mixer panel. In fact I don't even know how to adjust the volume without modifying the MIDI stream itself.
Is there a clean way to prevent more than one instance of the Player class existing at a time? Preventing multiple files being played by a Player instance is trivial, but is it reasonably obvious to a user that multiple player instances don't make much sense?
Ultimately: is MIDI support worth the effort on the off chance that some users might 'find it nice'? Especially when it means adding yet another dependency to xy which will likely go mostly unused.
@JonnyPtn feel free to rip any of this out for sfml-doom if it looks useful to you :)
So far a proof of concept - MIDI files can be loaded from disk and played back with the associated
Player
class. Current concerns:Player
class existing at a time? Preventing multiple files being played by aPlayer
instance is trivial, but is it reasonably obvious to a user that multiple player instances don't make much sense?@JonnyPtn feel free to rip any of this out for sfml-doom if it looks useful to you :)