Hi, I've not yet said so in appreciation of all the work you have done, and it must be shout: Thank you very much! :-)
About the patch: I want to commit it after the 1.0.9 release, because it has several ramifications that need to be developed further, and it has enough importance to deserve a complete cycle of testing, during several weeks or so. It may be ready to be released in FS 1.1.0 Things that I would change before the commit (if you don't beat me) * Setting "player.timing-source". Bad name, and bad place. The same setting would be used from the player and from the sequencer. But for me, it belongs to the synth and the type is boolean. Either you trigger the timer callback from the synth or you don't. That was my first proposal: synth.slave-timer = yes/no. * Define a new "slave-timer" member of _fluid_synth_t, and initialize it according to the corresponding setting in new_fluid_synth(). * fluid_sample_timer_process() is called unconditionally from fluid_synth_one_block(). This would impact the usage of FS when there are no timers needed (for RT-only clients) in a very sensitive place. Here you need to use the setting value. An "if" is much less expensive than a "call". * 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. * 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" :-) * 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. * "fluid_seq.c" should be converted to this timer, as discussed recently. I've only started testing the results, sorry. I have very little free time. But the preliminary results look very promising. Regards, Pedro _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
