"Several bug fixes to the engine, notably quite a few which could cause FluidSynth <http://sourceforge.net/apps/trac/fluidsynth/wiki/FluidSynth> to sound bad in some cases."
As I have previously experienced a sudden sound blast when loading a midi on the start in Windows 7. Has this issue been fixed in this update? On Fri, Aug 5, 2011 at 12:19 AM, Orcan Ogetbil <oget.fed...@gmail.com>wrote: > On Thu, Aug 4, 2011 at 11:27 AM, Pedro Lopez-Cabanillas wrote: > > On Thursday 04 August 2011, Orcan Ogetbil wrote: > >> On Thu, Aug 4, 2011 at 3:54 AM, David Henningsson wrote: > >> > In short, version 1.1.4 of FluidSynth brings us: > >> > > >> > * Several improvements and fixes to the CMake build system, > >> > especially for Mac OS X > >> > * Several bug fixes to the engine, notably quite a few which could > >> > cause FluidSynth to sound bad in some cases. > >> > * API additions, that make it possible to > >> > - load MIDI files from memory > >> > - to inspect/modify MIDI events as they are being played from a > >> > MIDI file > >> > - to change channels between melodic and drum mode > >> > - and to silence all notes in one command. > >> > * Improvements to the CoreAudio driver > >> > > >> > A more detailed list of changes is available at > >> > https://sourceforge.net/apps/trac/fluidsynth/wiki/ChangeLog1_1_4 > >> > > >> > Looking back at the changes, I'm feeling a little proud today. One of > the > >> > reasons for feeling proud, is that we have more than one new > contributor: > >> > people who have taken the step to actually work with the code, improve > it, > >> > and create non-trivial patches with new functionality in it. That is a > good > >> > foundation for the future and I hope all contributors feel welcomed > and > >> > properly attributed. > >> > > >> > Also, the improvements/fixes to the build system is worth a special > note > >> > (thanks Pedro!), I was surprised to see so many of them! And finally, > we've > >> > managed to close several long standing bugs, which makes me feel that > this > >> > release will be stable and enjoyable for a lot of people, with less > >> > annoyances than ever. (Thanks to the jOrgan folks for the test run!) > >> > > >> > Now, enjoy the release, and last but not least - make sure you make > some > >> > really great music with it! :-) > >> > > >> > On behalf of the FluidSynth developer team, > >> > David Henningsson > >> > > >> > >> Hi all, thanks for releasing 1.1.4. Sorry I did not have time to test > >> the prerelease tarball you made the other day. I was planning to do > >> this today. > >> > >> Anyhow, I saw in the CMakeLists.txt, a couple lines such as > >> ${CMAKE_INSTALL_PREFIX}/${LIB_INSTALL_DIR}${LIB_SUFFIX} ) > >> > >> Unfortunately this is wrong. The variable ${LIB_INSTALL_DIR} is > >> already expected to have the lib suffix in it, i.e. it is set to > >> /usr/lib64 on multilib 64bit systems. This is the cmake standard we > >> have with hundreds of packages in Fedora. > > > > This may be the standard in Fedora, but it is not a CMake standard at > all. You can ask in the CMake mailing list, or search for similar questions > in the archives, for instance: > > http://www.cmake.org/pipermail/cmake/2011-March/043180.html > > > > I've adopted the variable name "LIB_INSTALL_DIR" because i'm used to it > in my KDE projects, but it is not a standard outside KDE. The FluidSynth's > LIB_INSTALL_DIR is a constant defined in cmake_admin/DefaultDirs.cmake, with > the value "lib". The other variable LIB_SUFFIX is initialized in the main > CMakeLists.txt with the value "64" or empty. You can override the > initialization value of these variables in the command line, if you want: > > > > $ cmake .. -DLIB_SUFFIX="" > > > > This can be easily added to the RPM spec file too. I find this method > much more comfortable than applying patches. > > > > Hi Pedro, > > Sure the behavior can be overridden that way. However, when building > RPMs, there are cmake macros we use that pass all the standard flags > to all packages that use cmake. I am sure other RPM based > distributions, or even DEB ones use some sort of standardization in > cmake flags too. > > I really do believe that what I claimed is a (maybe unwritten) cmake > standard, since we do not have to do such overrides you suggested for > any other package (we have a lot of them). I also adopt this > convention in my projects where I am the upstream. Of course, > fluidsynth can be a special case, but does it really have to be? > > Thank you for your time, > > Orcan > > _______________________________________________ > fluid-dev mailing list > fluid-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/fluid-dev >
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
