Well, this commit got a bit out of hand, what with 26 files changed. Oh well.
Basically, we're using the buffermanager to dispense temporary buffers for playhandles and audioports to use.
This allows us to change the way playhandles work. Earlier, playhandles of the same track were waiting in line
to push their output to the audioport. This was of course inefficient, so now they just register themselves to the port,
then the port handles mixing the buffers.
Caveat: this is still a work in progress, the vol/pan knobs on instruments are temporarily non-functional - will be fixed in
the next commit, but I have to get some sleep now.
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.
- 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.
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.
Also removed all blocks similar to
```
#if QT_VERSION >= 0x040806
filedialog.setOption( QFileDialog::DontUseCustomDirectoryIcons );
#endif
```
as this now takes place in the new subclass's constructor.
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.
Path to VST plugin will be stored as relative, if plugin is opened
from default VST plugin path. Should remain compatible with project saves
from old releases or vice versa.
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>
Window title for VSTi parameter controlling window should be set according to
actual track name, not from VST plugin name as its now, it is hard to get to know
which window belongs to where when same plugin is e.g. opened several times, so
with the same name. Now this is handled in paint event, but TBD whenever is
that track name changed. tbd, temporary solution.
Signed-off-by: Tobias Doerffel <tobias.doerffel@gmail.com>
When you double-click on some knob to change its VST parameter value
manually, new dialog window now has same title as what was that knobs
name. (instead of "lmms" title string)
Signed-off-by: Tobias Doerffel <tobias.doerffel@gmail.com>
Filter to display only automated / all knobs (new button) on LMMS VST parametr control window.
Signed-off-by: Tobias Doerffel <tobias.doerffel@gmail.com>
After project save/load unsaved VST control parameters in LMMS VST control wrapper are not set to zero now, but reloaded according plugins saved state.
No need to sync values manualy again, after project save, load.
Signed-off-by: Tobias Doerffel <tobias.doerffel@gmail.com>
Only not automated values are synced from VST plugin, no need to sync already automated values.
Synced values are now not trackable with undo / redo, before all changes were tracked individualy,
but user could lose ability to undo easily changes before sync buton was pressed.
Signed-off-by: Tobias Doerffel <tobias.doerffel@gmail.com>
Fixed destuctors for various types of VST automation panel removal.
Automated signals correct disconection on panel removal.
When you load new VST plugin in the place of old one, while automation
is already connected and active there, this should not result in LMMS crash
or reuse of that old automation connections and automation window destructor
should not leave zombie VST plugins on application exit.
Signed-off-by: Tobias Doerffel <tobias.doerffel@gmail.com>
The code for managing programs/presets of RemotePlugin instances was
very confusing, mainly within the VstPlugin and RemoteVstPlugin class.
I therefore started to reorganize and rewrite functions.
