Exit the outer loop of processJobQueue() Only as soon as we went through
the job queue without having processed at least one job.
In MixerWorkerThread::waitForJobs() re-introduced "pause" instruction on
x86 and x86_64 giving better performance on HyperThreading systems.
These improvements however still do not solve all performance and
multithreading issues.
Calling FxMixerView::refreshDisplay causes LMMS to crash when running
in console mode. Therefore explicitely check GUI mode before calling
this function.
Declarations and implementations of MixerWorkerThread and ThreadableJob
have been moved into separate source files.
Furthermore there were some improvements to MixerWorkerThreads.
MixerWorkerThread::processJobQueue() does not return until the job
queue completely has been processed. This way each thread can "help"
to finish processing the queue and does not get back to sleep until
all of the work is done.
Management of the queue is now done via an array of QAtomicPointers.
Items that are non-NULL still need to be processed while NULL-items
were taken from the queue (i.e. in progress or done). Thus we do not
need to deal with ThreadableJob-states within MixerWorkerThread anymore.
The FxMixer now uses job threads to accomplish its mixing. It's
theoretically efficient, but there is a horrible thread bug
preventing the code from working. I've spent 5 hours debugging and
need some external help!
In Mixer, the old C-macro based code has been replaced by an OOP-like
design. Management of job queue now happens via some static member
methods of MixerWorkerThread. All the moved code still needs to be
splitted into some new files but here's a first dirty version.
All objects that are intended to be processed by MixerWorkerThreads
have to inherit ThreadableJob (name of class is subject of change).
One can add jobs to the job queue even if the queue is already being
processed. This is merely important for multithreading with upcoming
FX sends support.
Previously, the extensions were stored in the translations, this i18n
more difficult, additionally, there was a preprocessor statement that
would cause the translated phrase to change! Hence, no translations if
you didn't have ZIP file support. The text is now split into seperate
translations and I added "All Files".
This reverts commit dd260245ec.
The commit fixed the compilation problem but according to upstream
causes new problems because of the huge data structures on the stack.
Upstream provided a better patch which will be applied next.
The std::vector::data() method is a special feature of GCC and
therefore not portable. This causes a compile failure of CALF plugin
on OS X. Therefore I replaced the code with standard arrays
allocated on stack.
Upstream needs to be informed about this patch.
Thanks to Daniel Klaffenbach for pointing out this issue.
Source directory structure of the CALF plugin shipped with LMMS was
not equal with original one which makes cherry-picking commits from
CALF Git impossible.
In the Fx Mixer View, you can select a channel and press Alt+Left
and Alt+Right respectively to re-order Fx Channels. This should be
made more easily available in the GUI eventually.
* lock fx mixer height
Done. channelArea->setFixedHeight and proper sizeConstraints
* width: pick a good min. size. keep max. size off.
Done. Set to 6 fx-lines.
* effects chain should align to the right
Done.
* get rid of padding in mixer
Done. setSpacing and setMargin on chLayout
* scroll area so that vert scrollbar is never seen.
Done. setVerticalScrollBarPolicy and proper height calculation
* Get rid of scroll bar area border
Done. FrameStyle.
The biggest change, however, was removing the multiple EffectRackViews
that were being used. Now just a single EffectRackView exists and it is
shared by all models.
There's no need to call plugin dispatcher in hostCallback. It makes
plugins like Garritan Personal Orchestra 4 lock up. After removing
these calls the affected plugins work.
Commit 3c18e436cd makes it impossible to
build LMMS with embedded ZynAddSubFX if "-Wl,--as-needed" is used in
LINKER_FLAGS during the link step of RemoteZynAddSubFx:
Linking CXX executable RemoteZynAddSubFx
libZynAddSubFxCore.so: undefined reference to `fftwf_plan_r2r_1d'
libZynAddSubFxCore.so: undefined reference to `fftwf_execute'
libZynAddSubFxCore.so: undefined reference to `fftwf_destroy_plan'
This happens because fftw3f, which is a system lib, is linked to before
the ZASF core libs when linking RemoteZynAddSubFx. With "--as-needed",
correct library order matters.
Created a user interface so you can add and remove FX sends as
well as tweak how much you are sending. The gui does not
yet prevent the user from creating endless render loops.
Additionally, there seems to be some issues to work out regarding
rendering with multiple sends.
ZynAddSubFX has gained some new developer power so development has been
going on well for quite a while now in their Git repo. It's time for
the first big resync so future changes can be integrated easily.
OscilGen::tmpsmps and OscilGen::outoscilFFTfreqs were static member
variables initialized once in LocalZynAddSubFx class. However having
this data global is not a good idea because it gets modified by each
synth (possibly in parallel), causing heavy distortion under various
circumstances. Now that this data is allocated and used per-synth
everything works fine.
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.
QHttp is quite low-level while QNetworkAccessManager offers a well
designed API for accessing network resources. Therefore switched backend
of WebResourceProvider from QHttp to QNetworkAccessManager.
If DEBUG_REMOTE_PLUGIN was set, RemotePlugin::process() always returned
as RemotePlugin::isRunning() returned false. Fix this by always
returning true when debugging.
Added a new GUI-less mode to ZynAddSubFX instrument plugin which allows
to let ZynAddSubFX audio processing happen within LMMS, giving a much
better realtime behaviour.
As soon as showing up the GUI settings of GUI-less ZynAddSubFX instance
are saved and a traditional RemoteZynAddSubFx process is being launched
and the settings are applied there.
