Some plugins ignore updates to these values if they're changed while the plugin is in a "resumed" state, resulting in incorrect tuning after a change of sample rate.
From MSDN: "In WM_SYSCOMMAND messages, the four low-order bits of the
wParam parameter are used internally by the system. To obtain the
correct result when testing the value of wParam, an application must
combine the value 0xFFF0 with the wParam value by using the bitwise AND
operator."
Also calculate the required window size using AdjustWindowRect, rather
than hard-coding some constants.
Recent builds of MinGW64 runtime include the winpthreads library which
is not linked statically anymore and thus doesn't required non-portable
(de-)initialization function calls.
Newer versions of GCC seem to assume an array size of 0 for arrays whose
size is not specified explicitely. This causes a warning about an
out-of-bounds array access.
It seems 64bit builds for some reason have problems with VST Sync feature on,
workaround seems to be converting VST sync patch from double to floats,
which does work both with 32 and 64bit builds. Double precision
seems to produce odd numbers with 64bit build. (tested on VirtualBox Linux
Mint 14.1 64 bit OS)
(cherry picked from commit 011f87e6e60cccd16f3783e9c4885e03d95c1e56)
Signed-off-by: Tobias Doerffel <tobias.doerffel@gmail.com>
This patch should bring VST to host synchronization for LMMS.
(e.g. for plugins like dBlue Glitch, TAL Filters).
Synchronization is done via shared memory, missing song time
positions are reccalculated and added to PPQ position sync values
(SHM - common input interface for sync of all VST plugins)
Master channel keeps freezing, when VST effects are placed directly
into Master channels FxChain, on slower computers.
Provided solution prolongs VST initialisation phase, by waiting on two extra messages,
which usually follows initialisation and are possibly not yet implemented well.
IdSampleRateInformation,
IdBufferSizeInformation
This seems to prevent Master channel freezes e.g. on VST effects like Tiny-Q.
Signed-off-by: Tobias Doerffel <tobias.doerffel@gmail.com>
Various fixes improvements:
+ Added support for VST parameters control for windows.
+ New `Close` button for VST parameter controls.
+ Faster GUI for all instruments, effects-loading, not only VSTs,
and both one-instrument track window mode and normal window
mode should be supported.
+ Better integration for VST GUIs on Linux, e.g. plugin window
should not stay always on top of other windows.
+ VST GUI overlook should remain same with different wine setups
( except for whole virtual desktops emulations ).
+ VST effect control window merged with VST effect editor window
should be more easier to control.
+ Little corections at effectviews model updates of instrument
tracks effect chains.
Signed-off-by: Tobias Doerffel <tobias.doerffel@gmail.com>
src/core/RemotePlugin.cpp @ RemotePlugin::process
Above function should be now more thread safe, but functionality remains.
This prevent lmms locks, when automation is connected to lmms VST plugin wrappers controler / knob on Linux.
On win32 build whenever is lmms wrapper parameter controler / knob amended.
plugins/vst_base/VstPlugin.cpp @ VstPlugin::setParam
plugins/vst_base/RemoteVstPlugin.cpp @ RemoteVstPlugin::processMessage
In above functions we dont wait for message confirmation when parameter setter function finish, and dont send such confirmations.
This workaround prevent locks on Linux, whenever there is automation connected and if you try to move with VST plugin
(not via lmms plugins wrapper, but with VSTs internal window) than it freezes, on win32 build it will freeze whenever you connect
automation and than if you move your mouse above this VST plugin window.
Signed-off-by: Tobias Doerffel <tobias.doerffel@gmail.com>
