Fix a crash that occurred on the following steps:
1. Add an AFP track.
2. Open it, and move the waveform display to overlap the track label
button.
3. Close the AFP window and open it again by clicking the track label.
4. Move the mouse pointer.
The problem occurs because the code makes the implicit assumption that
AudioFileProcessorWaveView::enterEvent (and hence
QApplication::setOverrideCursor) is called before
AudioFileProcessorWaveView::mouseMoveEvent. This is not the case when
the waveform display is on top of the track label. In this case the AFP
windows is opened with the mouse being immediately positioned over the
wave form display. There is no enter event and move events are issues
directly. This then leads to a crash in
AudioFileProcessorWaveView::mouseMoveEvent when trying to determine the
value for is_size_cursor because the override cursor is still null but
is dereferenced directly without checking.
Only adding a check would not solve the problem because in that case the
cursor would not change to the hand cursor when being moved inside the
waveform display.
The solution is to remove all calls to the global methods
setOverrideCursor and restoreOverrideCursor and to only set the cursor
locally.
This fix is based on a patch by gi0e5b06 which is committed under 8a10c52
in his repository but for which he never created a pull request.
* Move m_key member of Effect into Plugin
* Pass key to Instrument ctors and instantiaters
* Add pluginKeys to all plugin selector widgets, and let them pass the keys
when instantiating the instruments; or, if the keys must be passed over
threads, pass the keys to the Engine using `Engine::setDndPluginKey()`
* As instrument plugin libraries now also need to get their key passed, their
second argument, which was always the same as the first, is now used to pass
the sub plugin keys. This affects *all* instrument plugins.
* Plugin.h: Add more virtuals to `SubPluginFeatures` in order to draw logos
and images into instrument selector widgets
* LadspaSubPluginFeatures: Implement the `displayName` virtual because the
new behaviour to resolve displayNames is to first look at the
SubPluginFeatures, which, without override, returns the superior plugin's
name (Plugin.cpp)
Additional:
* PluginFactory.h: Allow setting up search paths without discovering plugins
yet
* Plugin.h: Add full documentation (should be checked)
* Remove bin2res, use Qt's resource system
* Use QDir search paths and QImageReader in getIconPixmap
* Don't include "embed.cpp" in plugins
* getIconPixmap: Use QPixmapCache, use QPixmap::fromImageReader
* Require CMake 2.8.9
* Fix ReverbSC embed usage
LMMS now properly builds and runs with Qt5. Various deprecated functions
had to be replaced like QString::toAscii()/fromAscii(). Also occurences
of FALSE/TRUE have been replaced with false/true.
LmmsStyle now derives from QProxyStyle and sets a style instance as base
style (Plastique for Qt4, Fusion for Qt5).
MOC files are not included anymore but added as regular source files.
What's missing is support for embedding VST plugins into a subwindow
inside LMMS on Linux/X11 due to missing QX11EmbedContainer class in Qt5.
Build instructions can be found in INSTALL.Qt5
Minimum version requirement for Qt4 has been raised to 4.6.0 for best
API compatibility between Qt4 and Qt5.
- Stop pointlessly reloading the sample everytime the amp knob is changed
- Also draw the amplitude of the waveform correctly (used to be it was drawn as 2x too "quiet")
Change in handling of frameoffset for multistreamed instruments and sampletracks.
- Instead of holding the offset for the lifetime of the playhandle, negate the offset in the first period
- Multistream-instruments require some small changes: they have to now check for the offset and accordingly leave empty space in the start of the period (already done in this commit)
- There are possibly optimizations that can be done later
- This change is necessary so that we can have sample-exact models, and sample-exact vol/pan knobs for all instruments. Earlier multistream instruments were always rendering some frames ahead-of-time, so applying sample-exact data for them would have been impossible, since we don't have the future-values yet...
