fluid-dev
[Top][All Lists]
Advanced

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

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


From: David Henningsson
Subject: Re: [fluid-dev] Patch for fast midi file rendering
Date: Mon, 20 Apr 2009 22:08:45 +0200
User-agent: Thunderbird 2.0.0.21 (X11/20090409)

Josh Green skrev:
> 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.

Perhaps if you have a hardware sequencer which the input comes from, and
you want to output that to a file?

>>> * 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().

But the file name is already a setting as well. And the word "period
size" might sound like something more universal that "file name", but
both of them are only used in the audio drivers. Anyway this is not a
big deal to me, so if it is a big deal to anyone else, I'm willing to
adjust :-)

>>> * 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.

Seems like a good idea. Hopefully noone wants to create a file named "-"?

// David




reply via email to

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