Mix_LoadMUS does take a filename but an application can also call
Mix_LoadMUS_RW, which takes an SDL_RWops. All the existing backends
support this.
Ah, OK then. I was sort of expecting that (but didn't find it when I looked), since most SDL things let you take a RWop.
This may be oversimplifying things slightly. fluid_player_load isn't a
public function and the public player functions that are there all
revolve around the playlist. Each playlist entry only has one field,
which is the seemingly flexible "void* data" but this is currently
always treated as a filename. There is potential for this to work but
the specifics would need to be discussed first.
On the one hand, I've already done the hard work of using the sequencer
interface instead but being able to simply pass a file handle to
FluidSynth would cut the size of my SDL_mixer patch in half. It's
therefore a solution that's well worth investigating. It would also
sidestep the tempo issue, which may be harder to fix.
OK, well it would be exceedingly good to avoid duplicating all the MIDI event loading code. I don't think passing a file handle to FluidSynth would work in this specific case (or in several other general cases), because while SDL's RWop data structure does internally use a FILE*, that isn't part of the public interface to RWop. There would be similar problems if FluidSynth was extended to a C++ or Python wrapper -- how would you wrap this new proposed function? In C++ it would be expected to take an iostream, and in Python it would typically be expected to work on any object with a read() method.
Therefore I think David's suggestion is more extensible -- a function which takes a void* pointing to an already-loaded MIDI file in memory and loads it. Then the SDL_mixer backend can read all the bytes from the RWop into memory before passing it to FluidSynth; the C++ wrapper can load from an IOStream; the Python wrapper can read() into a memory buffer, etc.