* 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)
Moving empty destructors out of the .cpp files and into headers
allows them to be devirtualized in certain cases.
(When the compiler can't "see" a function in a header, it must largely
assume it's some black box that the linker will resolve.)
While we're at it, use C++11's `= default` to define empty virtual
desturctors for us.
For some classes (e.g., Piano), nothing is derived from it, so we can
mark the class as final and remove any explicit virtual dtor.
There are many other places where this can be done, but this is a large
enough patch as-is.
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.
Issue: Currently, we use threads to process all PlayHandles, so there's no guarantee of the order they are processed in. This causes timing inaccuracy and jitter: notes of instruments that use both NPH's and IPH's can get randomly delayed by one entire period.
The issue is solved thusly:
- When processing an IPH, we check if the instrument is midi-based. If yes, we just process it normally (no NPH's to worry about).
- If it's not, then it also uses NPH's, so we'll have the IPH wait until all NPH's belonging to same instrument have been processed. There's some similar code in the new FX mixer, I pretty much just copied how we do it there.
- currently only affects Vestige
- no idea whether this can also be used for Zyn and OpulenZ, I'm not sure if Zyn has any kind of mechanism for communicating frame offset to the synth, as for OpulenZ, @softrabbit would know the answer better
- basically, I made it happen by simply adding an extra parameter in the processMidi{In|Out} functions, which is 0 by default, and made the necessary changes in instrumentTrack and nph to utilize it
- I based this against 1.1 because I didn't think it's a very big change, and I don't see much possibility for things going wrong here, since we're basically just using the existing functionality in Vestige (there already was a frame offset being communicated to the remote plugin, just that it was always set to 0). However, if @tobydox thinks this is better to bump up to 1.2, I can rebase it for master...
There'll be more and more flags for instruments. Handling them using
virtual and overloaded getter functions doesn't scale well and adds
unneccessary overhead.
Next big coding style update - this time all PlayHandle classes are
affected. Functions like done() and released() were renamed to
isFinished() and isReleased().
The MIDI event handling in InstrumentTrack was complex and buggy. It has
been simplified now such that processInEvent() tries to handle note on,
note off and key pressure events. The actions taken should result in
equivalent calls to processOutEvent() by NotePlayHandle instances. The
processOutEvent() function sends according MIDI events to the attached
instruments. All unhandled MIDI events are directly forwarded to the
instrument in processInEvent().
It's possible that some corner-cases are not handled yet with the new code
and we have regressions now.
Furthermore renamed midiTime/midiEvent to MidiTime/MidiEvent to match
coding style.
Closes#72.
In order to provide smooth muting functionality (i.e. immediate proper
sound when unmuting) always render audio buffers for MIDI-based
instruments. This is more important than potentially reduced CPU usage
while muted.
Closes#69.
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.
(cherry picked from commit 6940d19969)
Most files and most of the core classes and their methods have been
renamed to match new coding style conventions:
391 files changed, 25400 insertions(+), 25598 deletions(-)
Furthermore splitted some files where model and view classes were
declared or implemented together in the same file.
Should be tested thoroughly as I might have missed renaming some virtual
methods or SIGNAL/SLOT parameters.
(cherry picked from commit 8c9a9dd14c)
