Re: fluidsynth 2.0
Hi Felipe, Felipe Sateler wrote: > I think the first step would be to prepare a package targeting > experimental, see how much stuff fails to build and how hard it is to fix. thanks for the heads-up! As the one who uploaded the last two 1.x packages, I agree this is the right way to go. However, I have no plans to undergo the API transition myself, so please don't count on me. I currently have a 2 months old baby at home and don't even use the library myself apart from occasionally playing SDL2_mixer-using games. My reason for uploading the previous packages was that it included a patch by me which added support for playing SF3 format sound fonts. > With that info, it can be decided if it's best to keep both or port all > apps to version 2.0. My impression is that upstream has abandoned the 1.x series and we should be wise enough to do the same in Debian. Thanks, - Fabian
Re: fluidsynth 2.0
Hello Felipe, thanks for the explanation. Currently I'm a bit too busy to take care about this. Version 2.0 introduced a seek function (among other changes). This seek function was originally implemented by Willem Vree and is available on his website in the form of modified files for an older fluidsynth version. There is also a Python binding which needs this seek function. Someone else suggested to integrate the seek function into fluidsynth, but the upstream maintainer requested changes to the code. Willem Vree found some problems with the modified implementation compared to his original one, at least on his system. Unfortunately I was not yet able to reproduce the problems. My system is different, maybe the problem occurs only in a certain environment. I plan to prepare a newer hardware for re-testing and solving the problems in the seek function. Felipe Sateler wrote: On Fri, Oct 26, 2018 at 5:05 AM Bodo Meißner wrote: Is there a way to handle incompatible and conflicting libfluidsynth-dev versions? For example source package A build-depends on libfluidsynth-dev <2.0.0, source package B and build-depends on libfluidsynth-dev >= 2.0.0? Until now I didn't find information about this topic. Links to related documentation are welcome. But does it make any sense to keep both versions? Does fluidsynth upstream plan to continue supporting both? fluidsynth.org shows only releases for version 2.0 after 1.1.11 (May 2018) and the 1.1.x releases are mainly bugfixes, so there doesn't seem to be any current development for 1.x. I agree that at some time all applications should switch to fluidsynth 2.0. I think the first step would be to prepare a package targeting experimental, see how much stuff fails to build and how hard it is to fix. With that info, it can be decided if it's best to keep both or port all apps to version 2.0. I think I will dig into the problems with the seek function first because that's what is needed to use fluidsynth for EasyABC which I'm interested in. Best regards, Bodo
Re: fluidsynth 2.0
(Sorry, this seems to have gotten stuck in the drafts folder) On Fri, Oct 26, 2018 at 5:05 AM Bodo Meißner wrote: > Hello Felipe, > > thanks for the hint. > > Zitat von Felipe Sateler : > > > I think the more relevant question is whether version 2.0.0 introduced > any > > backwards-incompatible change. > > According to the documentation, version 2.0.0 introduced incompatible > API changes, not only adding new functions. > Bummer. Hopefully the API changes don't impact everyone. > > If so, then it probably needs fixing in all > > reverse dependencies before it can be updated. > > For the binary library this can probably be handled by installing both > libfluidsynth1 and libfluidsynth2 packages. > Right. > > Is there a way to handle incompatible and conflicting > libfluidsynth-dev versions? > For example source package A build-depends on libfluidsynth-dev > <2.0.0, source package B and build-depends on libfluidsynth-dev >= > 2.0.0? > Until now I didn't find information about this topic. Links to related > documentation are welcome. > But does it make any sense to keep both versions? Does fluidsynth upstream plan to continue supporting both? > Or does this mean that all packages that build-depend on > libfluidsynth-dev would have to be changed to use version >= 2.0.0? > I think this is the more viable option. The number of packages is not large (I see 24), and many are maintained here in this team. I think the first step would be to prepare a package targeting experimental, see how much stuff fails to build and how hard it is to fix. With that info, it can be decided if it's best to keep both or port all apps to version 2.0. -- Saludos, Felipe Sateler
Re: fluidsynth 2.0
Hello Felipe, thanks for the hint. Zitat von Felipe Sateler : I think the more relevant question is whether version 2.0.0 introduced any backwards-incompatible change. According to the documentation, version 2.0.0 introduced incompatible API changes, not only adding new functions. If so, then it probably needs fixing in all reverse dependencies before it can be updated. For the binary library this can probably be handled by installing both libfluidsynth1 and libfluidsynth2 packages. Is there a way to handle incompatible and conflicting libfluidsynth-dev versions? For example source package A build-depends on libfluidsynth-dev <2.0.0, source package B and build-depends on libfluidsynth-dev >= 2.0.0? Until now I didn't find information about this topic. Links to related documentation are welcome. Or does this mean that all packages that build-depend on libfluidsynth-dev would have to be changed to use version >= 2.0.0? Best regards, Bodo
Re: fluidsynth 2.0
Hi On Thu, Oct 25, 2018, 07:21 Bodo Meißner wrote: > Hello Multimedia team, > > is there a plan to add packages for fluidsynth version 2.0.x? (current > version is 2.0.1) > > In version 2.0.0 the API function fluid_player_seek() and related > functions were added to libfluidsynth. This function is used by music > players to start at a specific position in the score. > I think the more relevant question is whether version 2.0.0 introduced any backwards-incompatible change. If so, then it probably needs fixing in all reverse dependencies before it can be updated. If not, then it is just a matter of updating the package. I'm sure patches for that are very welcome ;) Saludos
