Lmms routes all midi notes to ZSAF on channel 0, however the CC messages
not routed, and could erronusoly be sent on other channels. This would
lead to ZSAF not acting on these midi commands
This pull request routes All Midi CC messages to channel 0
fixes#1953
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.
Imported current head of LMMS-specific ZynAddSubFX source code.
The current code is based on version 2.4.4 of ZynAddSubFX.
HEAD: 9a993c4936ce987bb30f93eee2a573466ece3712
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.
- 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...
When loading some presets the PADnoteParameters spectrum size is 524288
or even bigger resulting in a stack allocation of 2 MB or more.
This results in a stack overflow on Win32 and thus crashes LMMS. Fix this
by allocating the spectrum on the heap instead.
Closes#543.
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.
When opening the ZynAddSubFX GUI the buffer size information was not
retrieved properly and caused problems when setting a low global buffer
size in LMMS. We update the buffer size in ZynAddSubFX manually now as
as a temporary workaround until the VST synchronization feature gets
stripped out of the RemotePluginClient class.
Closes#335.
Even though ZynAddSubFX does not support updating its pitch wheel range
via MIDI events we can set it manually using provided internal functions.
Closes#394.
