If you look *carefully* to the Jack driver in trunk, you would notice that two functions, new_fluid_jack_audio_driver() and new_fluid_jack_audio_driver2() are still there: http://fluidsynth.resonance.org/trac/browser/trunk/fluidsynth/src/fluid_jack.c
What has changed is that the first function is now calling the second one, the same design used in most other audio drivers. Bernat coded the solution in the 2.0 branch, and I tested and backported his code to trunk. This has been discused already in the mailing list. In addition to better structured code, this change was made to fix the ticket #21 in FS, and a similar bug report existing in QSynth: allow multiple audio outputs while the output meters are enabled. http://fluidsynth.resonance.org/trac/ticket/21 http://sourceforge.net/tracker/index.php?func=detail&aid=2538954&group_id=93509&atid=604538 On Tue, Mar 10, 2009 at 1:00 AM, Josh Green <j...@resonance.org> wrote: > On Mon, 2009-03-09 at 23:53 +0000, Rui Nuno Capela wrote: >> Josh Green wrote: >> > I just committed support for Jack MIDI to SVN. I tested this with >> > jack_midiseq. Also tested with alsaseq2jackmidi by connecting up my >> > MIDI keyboard to FluidSynth using that program as a bridge. >> > >> > Some details of the Jack MIDI driver: >> > - Creates a separate Jack client called fluidsynth-midi (sharing the >> > Jack client instance would be awkward in the FluidSynth code) >> > >> > - Added a midi.jack.id option for specifying the Jack client name >> > >> > - Creates an input port called "midi" >> > >> > I noticed that the jack_audio_driver2 stuff got removed. I think I saw >> > something like this being discussed on the list. Note that the driver2 >> > code is used by programs like QSynth to provide audio meters. My guess >> > is that removing this code probably broke that functionality. >> > >> >> sorry to chime in this late :) >> >> yes, qsynth uses new_fluid_audio_driver2() for the audio output meters; >> not sure how this relates to the (dis)appearing stuff. >> >> in any case, as in general, it is my understanding of shared library >> version-ing that, when at least one exported symbol gets dropped or >> changed, you must increment the library version age, eg. make it 1.1.0 >> and not 1.0.9. the latter would assume there's only additions to the api >> which doesn't seem to be the case, or is it? >> >> just my 2c. >> >> seeya > > > Hey Rui, > > The plan is to keep binary compatibility with the previous version of > FluidSynth, so we shouldn't be dropping symbols at this point. I'll > make sure things are sorted out before release. > > Cheers! > Josh > > > > > _______________________________________________ > fluid-dev mailing list > fluid-dev@nongnu.org > http://lists.nongnu.org/mailman/listinfo/fluid-dev > _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
