Still QString::toAscii() & friends were used in several places causing
problems such as failed access to files with non-ASCII characters in
name.
Closes#2884115.
For some reason CMake constructs a strange linker command line when
building RemoteZynAddSubFx.exe (win32) resulting in tons of undefined
and duplicate symbols.
The issue can be fixed by explicitely adding -lZynAddSubFxCore to
the library list and add an according dependency.
I mistakenly updated FLTK in master branch too so everything's a mess
when merging in master. Reverting bbe967e3a0
allows easy merge of master branch later.
Updated FLTK to SVN revision 6921 of branch-1.3:
- Managing all Widget flags in a single location now (STR #2161)
- Fixed all color related call to Fl_Color type (STR #2208)
- File chooser preview now recognizes utf8 encoded
text files (STR #2218)
- Empty functions in Fluid no longer create an
implementation (STR #2259)
- Fixed Fluid dependency on X11 (STR #2261)
- Updated the bundled libpng to v1.2.40 (released Sep. 10, 2009)
- Fixed Fl_Choice contrast with light-on-dark settings (STR #2219)
- Fixed X server "lock", if a modal dialog window is opened
while a menu is active (STR #1986)
- Updated mirror sites in documentation (STR #2220)
- Setting a default font for Xft (STR #2216)
- Temporarily limited builds to 32-bit on OX S to stay
compatible to Snow Leopard
- Fixed Windows compile bug with "#define USE_COLORMAP 0"
(STR #2241)
All versions of OS X except Snow Leopard ship GCC 4.0 which does not
understand the "-finline-functions-called-once" flag. Therefore do not
use this flag when building for OS X.
Restylized entire codebase to deal with inconsistencies.
This was done with an automated run of uncrustify, so there may be some odd
formatting for now.
The guidelines for formatting are in place at the sourceforge website and all
known changes appear to fully match them.
(cherry picked from commit 09ae8d044ad3352bec24f9bc3da5d35c3a3ba773)
This reverts commit dd260245ec.
The commit fixed the compilation problem but according to upstream
causes new problems because of the huge data structures on the stack.
Upstream provided a better patch which will be applied next.
The std::vector::data() method is a special feature of GCC and
therefore not portable. This causes a compile failure of CALF plugin
on OS X. Therefore I replaced the code with standard arrays
allocated on stack.
Upstream needs to be informed about this patch.
Thanks to Daniel Klaffenbach for pointing out this issue.
Source directory structure of the CALF plugin shipped with LMMS was
not equal with original one which makes cherry-picking commits from
CALF Git impossible.
Updated FLTK to SVN revision 6909 of branch-1.3:
- Managing all Widget flags in a single location now (STR #2161)
- Fixed all color related call to Fl_Color type (STR #2208)
- File chooser preview now recognizes utf8 encoded
text files (STR #2218)
- Empty functions in Fluid no longer create an
implementation (STR #2259)
- Fixed Fluid dependency on X11 (STR #2261)
- Updated the bundled libpng to v1.2.40 (released Sep. 10, 2009)
- Fixed Fl_Choice contrast with light-on-dark settings (STR #2219)
- Fixed X server "lock", if a modal dialog window is opened
while a menu is active (STR #1986)
- Updated mirror sites in documentation (STR #2220)
- Setting a default font for Xft (STR #2216)
- Temporarily limited builds to 32-bit on OX S to stay
compatible to Snow Leopard
- Fixed Windows compile bug with "#define USE_COLORMAP 0"
(STR #2241)
There's no need to call plugin dispatcher in hostCallback. It makes
plugins like Garritan Personal Orchestra 4 lock up. After removing
these calls the affected plugins work.
The SVN version of Fluid does not create implementations for empty
functions anymore. This made some source files miss some required
functions. Fix this by rebuilding with a better version of Fluid.
Commit 3c18e436cd makes it impossible to
build LMMS with embedded ZynAddSubFX if "-Wl,--as-needed" is used in
LINKER_FLAGS during the link step of RemoteZynAddSubFx:
Linking CXX executable RemoteZynAddSubFx
libZynAddSubFxCore.so: undefined reference to `fftwf_plan_r2r_1d'
libZynAddSubFxCore.so: undefined reference to `fftwf_execute'
libZynAddSubFxCore.so: undefined reference to `fftwf_destroy_plan'
This happens because fftw3f, which is a system lib, is linked to before
the ZASF core libs when linking RemoteZynAddSubFx. With "--as-needed",
correct library order matters.
ZynAddSubFX has gained some new developer power so development has been
going on well for quite a while now in their Git repo. It's time for
the first big resync so future changes can be integrated easily.
OscilGen::tmpsmps and OscilGen::outoscilFFTfreqs were static member
variables initialized once in LocalZynAddSubFx class. However having
this data global is not a good idea because it gets modified by each
synth (possibly in parallel), causing heavy distortion under various
circumstances. Now that this data is allocated and used per-synth
everything works fine.
While regular instruments were excluded from processing when muted
this did not happen for InstrumentPlayHandle-based instruments. Muting
for exampling tracks with VSTi's inside did not decrease CPU usage.
Checking whether related InstrumentTrack is muted before calling
Instrument::play() fixes this issue.
Closes#2857426.
