Week 28/2012: FluidSynth, Signing for Mountain Lion
We have decided to alter our weekly blogging practice slightly as recently we've been having difficulties syncing our posts. I will try to post my notes in time for Monday's build; DaniJ will post later in the week when he gets the chance.
I started the week by finishing up with the player color translation improvements. Hexen's Fighter class now uses the yellow color in single-player games and I fixed a bug in restoring the translation tables after engine reset, which was causing player sprites to turn completely black.
I was then planning to work on the Input drivers proposal, but as I was browsing through the Bug Tracker I was reminded of something I initially explored back in December: using FluidSynth for playing MIDI music with SF2 soundfonts. FluidSynth takes an SF2 soundfont and a MIDI file and converts it to plain WAV audio data -- or in our case, raw PCM samples. Given a decent soundfont, the end result is much improved music quality when playing the original MUS/MIDI music.
It took only a couple of days to take the FluidSynth sources and put together a new audio plugin for Doomsday called "dsFluidSynth". It implements Doomsday's Music audio interface and passes any MIDI songs over to FluidSynth's synthesizer. The resulting raw sample data is then played back using the same audio plugin that plays Doomsday's sound effects. I ended up with this arrangement because I opted to build an embedded, stripped-down version of FluidSynth with no audio output capabilities of its own.
While dsFluidSynth now works rather well, there are still a few important caveats: I didn't yet get a chance to configure the Windows autobuilder so that it can compile dsFluidSynth, and only the FMOD audio plugin supports raw sample feedback from another audio plugin. As FluidSynth has originated from the Unix world, it has been built on GLib. While it is possible to set up GLib for Windows development, it is not exactly trivial. We will look into it at a later point in time. We can also update (some of) the other audio plugins so that they can work with dsFluidSynth's output.
dsFluidSynth is still in a separate work branch, but I'm looking into merging it into the master for Friday's build.
With the release of OS X Mountain Lion imminent, I started looking into signing Doomsday with an Apple Developer ID. I modified the Mac autobuilder to sign the applications, but didn't have a chance to test if it actually works. I will try it with today's build 563.
The plan for this week is to finalize the dsFluidSynth work for non-Windows platforms and then start switching my focus to the to-do list and Bug Tracker in preparation for the stable 1.9.9.
I started the week by finishing up with the player color translation improvements. Hexen's Fighter class now uses the yellow color in single-player games and I fixed a bug in restoring the translation tables after engine reset, which was causing player sprites to turn completely black.
I was then planning to work on the Input drivers proposal, but as I was browsing through the Bug Tracker I was reminded of something I initially explored back in December: using FluidSynth for playing MIDI music with SF2 soundfonts. FluidSynth takes an SF2 soundfont and a MIDI file and converts it to plain WAV audio data -- or in our case, raw PCM samples. Given a decent soundfont, the end result is much improved music quality when playing the original MUS/MIDI music.
It took only a couple of days to take the FluidSynth sources and put together a new audio plugin for Doomsday called "dsFluidSynth". It implements Doomsday's Music audio interface and passes any MIDI songs over to FluidSynth's synthesizer. The resulting raw sample data is then played back using the same audio plugin that plays Doomsday's sound effects. I ended up with this arrangement because I opted to build an embedded, stripped-down version of FluidSynth with no audio output capabilities of its own.
While dsFluidSynth now works rather well, there are still a few important caveats: I didn't yet get a chance to configure the Windows autobuilder so that it can compile dsFluidSynth, and only the FMOD audio plugin supports raw sample feedback from another audio plugin. As FluidSynth has originated from the Unix world, it has been built on GLib. While it is possible to set up GLib for Windows development, it is not exactly trivial. We will look into it at a later point in time. We can also update (some of) the other audio plugins so that they can work with dsFluidSynth's output.
dsFluidSynth is still in a separate work branch, but I'm looking into merging it into the master for Friday's build.
With the release of OS X Mountain Lion imminent, I started looking into signing Doomsday with an Apple Developer ID. I modified the Mac autobuilder to sign the applications, but didn't have a chance to test if it actually works. I will try it with today's build 563.
The plan for this week is to finalize the dsFluidSynth work for non-Windows platforms and then start switching my focus to the to-do list and Bug Tracker in preparation for the stable 1.9.9.