Recent versions of SDL_Mixer allow for rendering MIDI songs using
the fluidsynth backend and recent versions of fluidsynth allow for
using soundfonts in SF3 format (which contain OGG compressed samples).
The midiproc process currently assumes that it is possible to remove
the temporary music file immediately after Mix_LoadMUS() has been
called, which is true if the music is rendered using Windows's limited
intrnal MIDI playback. However, when using an advanced backend like
fluidsynth, this file maybe locked by this library. Furthermore,
midiproc currently assumes that it is possible to override the
temporary music file as soon as Mix_HaltMusic() has been called which
is again not true if fluidsynth is used. In this case, this is only
possible after Mix_FreeMusic() has been called (and returned).
Additionally, we increase the time-out value after which we give up
waiting for the midiproc process to send an acknowledgement to 1s to
give it some time to load the fluidsynth library and a soundfont
(although 1s will still not be enough for soundfonts in SF3 format
which reportedly load up to the order of 10s!).
More specifically, because Mix_LoadMUS() fails, e.g. because it does not
recognize the music lump's file format. Music lumps are not always in
MUS or MIDI format nowadays, so let other code handle that.
- The process will now cut the music and shut down when Chocolate Doom
does.
- The process will now peacefully coexist with music overrides, such as
digital music packs.
Since I had communication working, I then completely reworked the
original interface to cater to Chocolate Doom. A couple of hours
later, I finally have a working prototype - launching Chocolate Doom
will play music, and you can control the music volume independently of
the sound effects.
Unfortunately, as it turns out, SDL_net does not allow you to create a
TCP listening socket that only listens on localhost. This has the
unfortunate side-effect of showing a firewall message, which is not
desirable.
Instead, I use pipes to communicate with the subprocess over stdin.
This approach actually works - the current state of the code is if you
launch Chocolate Doom, it will communicate with the subprocess.
This is only the beginning. Although communication is occurring, I
don't appear to actually be able to hear anything, and Chocolate Doom
crashes as soon as there is an attempt to switch songs.
This functionality allows us to read data out of a buffer without
irrevocably consuming it. We read what we can, and when we're done we
throw the reader away.
The plan is to read as much of a stream of data as is available, and if
we can't read a complete message, we simply toss the reader away and
try again when we get more data. I think that perhaps this strategy
might be easier than coming up with a state machine to parse the stream.
Please do not advance the underlying buffer while trying to use a
reader.
