Week 29/2012: dsFluidSynth merged, importing Hawthorn tech
Last week I merged my work on FluidSynth to the master and did some preparations for importing a batch of new tech from the Hawthorn research branch.
As I explained in last week's post, recently I've been looking into supporting SF2 soundfonts for MIDI playback. The status of this work is described in the proposal: it is currently functional with FMOD for Linux and Mac OS X (10.6+) and is included in the distribution packages for those platforms. It is not functional or present in the Windows package due to the technical issues detailed in the previous post. Sometime after the stable 1.9.9 I intend to revisit this and add support for Windows and other audio drivers.
There are some instructions in the wiki on how to use SF2 soundfonts using the unstable builds.
I felt I needed to boost my motivation a little before committing myself to the to-do list and debugging, so I took a look at the Hawthorn research branch and selected a bunch of tech for importing into libdeng2. While my primary target was the revised Hawthorn scripting engine, it has important tie-ins to the libdeng2 File System, so I decided to bring it over as well. Together these are a sizable portion of the functionality I wrote in the Hawthorn branch some years ago, and it feels very good to be finally integrating them to the main code base.
I've only started with updating the code for our modern conventions and it resides in a separate work branch called "scriptsys". I believe it will take until well after 1.9.9 is out before this can be merged to the master -- I want to round out the integration of the scripting engine and de::FS into the rest of the engine before pushing this out to everybody. It makes little sense to just add a bunch of code to the master branch without taking advantage of it anywhere.
My plan for this week is to shift focus over to the stable to-do list and start the effort of polishing things up for the stable 1.9.9. Previously this has been the point where we switch over to Candidate mode; however, with the experience gained from the previous two rounds, I have decided to keep the master tagged Unstable for a bit longer until we clear the stable to-do list somewhat and make sure all the on-going eligible work has been merged to the master. The Candidate mode will kick in when the amount of expected changes is low enough.
As I explained in last week's post, recently I've been looking into supporting SF2 soundfonts for MIDI playback. The status of this work is described in the proposal: it is currently functional with FMOD for Linux and Mac OS X (10.6+) and is included in the distribution packages for those platforms. It is not functional or present in the Windows package due to the technical issues detailed in the previous post. Sometime after the stable 1.9.9 I intend to revisit this and add support for Windows and other audio drivers.
There are some instructions in the wiki on how to use SF2 soundfonts using the unstable builds.
I felt I needed to boost my motivation a little before committing myself to the to-do list and debugging, so I took a look at the Hawthorn research branch and selected a bunch of tech for importing into libdeng2. While my primary target was the revised Hawthorn scripting engine, it has important tie-ins to the libdeng2 File System, so I decided to bring it over as well. Together these are a sizable portion of the functionality I wrote in the Hawthorn branch some years ago, and it feels very good to be finally integrating them to the main code base.
I've only started with updating the code for our modern conventions and it resides in a separate work branch called "scriptsys". I believe it will take until well after 1.9.9 is out before this can be merged to the master -- I want to round out the integration of the scripting engine and de::FS into the rest of the engine before pushing this out to everybody. It makes little sense to just add a bunch of code to the master branch without taking advantage of it anywhere.
My plan for this week is to shift focus over to the stable to-do list and start the effort of polishing things up for the stable 1.9.9. Previously this has been the point where we switch over to Candidate mode; however, with the experience gained from the previous two rounds, I have decided to keep the master tagged Unstable for a bit longer until we clear the stable to-do list somewhat and make sure all the on-going eligible work has been merged to the master. The Candidate mode will kick in when the amount of expected changes is low enough.
Comments