On Thu, 7 Oct 2010 10:42:22 +1100 Matt Giuca <matt.gi...@gmail.com> wrote:
> > I did. The main problem was that it only takes a file path, not a > > file handle. I looked at whether it would be easy to add a function > > for this but it didn't seem to fit into the playlist design. > > > > True, the fluid MIDI file player doesn't extend to anything other > than files (by name). But looking at Mix_LoadMUS (in SDL_mixer), > which I assume you are extending, most of the music types pass char* > file (the filename) along to the music format loaders. Can't you do > the same to fluid? 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. > If you do want to load data from a non-file (such as an SDL RWop), it > seems you'd just need to replace the functionality of > fluid_midi_file_get_division and fluid_midi_file_load_tracks (the > only operations performed on the midifile object itself by > fluid_player_load in midi/fluid_midi.c) -- not actually deal with > interpreting the track data itself (you wouldn't need to know the > semantics of each individual event). 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. James _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev