fluid-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] FluidSynth backend for SDL_mixer


From: James Le Cuirot
Subject: Re: [fluid-dev] FluidSynth backend for SDL_mixer
Date: Sat, 9 Oct 2010 23:09:44 +0100

On Thu, 7 Oct 2010 10:42:22 +1100
Matt Giuca <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]