Re: [fluid-dev] Patch for bad MIDI timing (with large buffer sizes)

[David Henningsson]

Pedro Lopez-Cabanillas skrev:
> David Henningsson wrote:
>> So after having improved the midi player patch a bit, I went to try
>> fixing #15, but I'm a little unsure of how to implement it in the file
>> driver the best way.
> [...]
>> Or should we bypass the generic audio driver and make fluidsynth.c
>> depend directly on aufile? Or perhaps even create a separate driver for
>> this purpose?
> 
> After thinking again about this, yes. The audio file driver is used for a 
> different thing, and it would be a mess if you try to convert it for this 
> purpose.

The downside to this approach is if/when we decide we want to output the
file in another format (wave/ogg/etc), having two different file output
routines is not good. And I think I can keep it non-messy :-)

> So, what about creating a new public function, say fluid_midi_renderer() or 
> something like that, with two parameters: a MIDI input, and an audio output 
> file names. Set the slave timer on it, initialize the MIDI player, and do a 
> simple loop, writting audio buffers to the output file until the player has 
> finished. It is not needed a new driver, nor a thread. If you prefer, create 
> a new set of functions fluid_midi_renderer_* with a callback for the clients 
> wanting to write the output file by themselves.

I prefer adding a fluid_player_get_status function to the public API.
Then the library user can write his own loop (and possibly add more
logic in it, he might want to check if the user pressed a cancel button,
update a progress bar etc).

> What I mean is that the MIDI rendering process, faster than realtime, is a 
> totally new and different problem, and so the solution should also require a 
> new interface.

We could introduce a new interface to the public API -
new_fluid_file_renderer(synth),
delete_fluid_file_renderer(file_renderer),
fluid_file_renderer_process_block(file_renderer). Under the hood we
redirect these calls to a modified fluid_aufile.c. What do you think
about that?

// David