> 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.
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
