Re: [fluid-dev] Patch for fast midi file rendering

[Josh Green]

On Sun, 2009-03-22 at 06:46 +0100, David Henningsson wrote:
> > * fluid_renderer* is another bad name. It is not rendering anything, in the 
> > sense of translation, like the verb used in "rendering SVG into bitmap 
> > graphics". The proposed functions are only audio file helpers, because you 
> > don't include the MIDI player into the scope. 
> 
> It's the synth that renders MIDI into samples, and the file_renderer is
> a wrapper around the synth for doing just that, and then to write it to
> a file. But I'm open for better suggestions.
> 


I agree that render fits the function of what FluidSynth is doing
(rendering SoundFont instruments and MIDI files to audio).  I'd just as
well do away with the file writer driver, since I don't see a need for
live file writing using FluidSynth directly (since you would likely want
to hear it as well, which means something like Jack would be better) and
other APIs, such as what you are suggesting, would be better suited for
faster than realtime rendering.  I suppose there isn't too much harm
done by leaving it around though.


> > * new_fluid_file_renderer() has a parameter "period_size", that is 
> > available 
> > as a setting. Instead, I would prefer to read synth->setting inside this 
> > function. You may have access here to "fluid_synth.h" :-)
> 
> I guess that's a matter of taste. But for the sake of consistency, the
> filename should be read from the settings then as well.
> 


Hmm, I'm not sure about this one.  The settings seem like a nice way to
group options in one place, a registry of sorts.  Its useful to the user
and helps prevent the need to modify API function calls.  I can see in
that case how period_size could make sense, as it is already there.  The
filename on the other hand, seems more specific to the case where the
renderer is writing to a file (rather than say a user callback
function).  I could see that as being a parameter to
new_fluid_file_renderer().


> > * The raw audio format is not very useful by itself, but can be converted 
> > to 
> > anything else, for instance to mp3 with lame. It would be nice to send the 
> > output to stdout if the file name is not specified, so the output of FS can 
> >  
> > be piped to lame.
> 
> I'm not sure if that would work? If you call "fluidsynth -F mybank.sf2
> myfile.mid", it would assume that you want to output to mybank.sf2. So I
> guess we'll have to stick to the somewhat messier "fluidsynth -F
> /dev/stdout mybank.sf2 myfile.mid" if you want to pipe it further.
> 


I like the use of '-' to indicate stdout.  That is common to many
applications and would save the user from accidentally getting a
terminal full of seemingly endless junk.


> We must also make sure that fluidsynth does not make any noise on
> stdout, but I don't know if that is a problem.
> 

>From what I can see in src/fluid_sys.c the FLUID_LOG stuff logs to
stdout on WIN32 systems and stderr on others.  We could consider any
logging to stdout a bug and fix accordingly, if the stdout becomes used
for audio rendering through a pipe (a nice feature!).

> Anyway, if we have any good examples for rendering to wave/mp3/ogg/etc,
> that could be written in the man page.
> 
> > * "fluid_seq.c" should be converted to this timer, as discussed recently.
> 
> Agreed, but I don't have a test environment for the sequencer here.
> Either we leave this up to Antoine or I'll have to install a test
> environment somehow. Anyway I prefer to have it in a separate patch.
> 
> // David
> 

        Josh