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.
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.
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.
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.
Instead of writing QVector<Plugin::Descriptor> everywhere, mit up
iterators etc. centrally define Plugin::DescriptorList and use it
everywhere.
Additionally made pointers to Plugin::Descriptor and
Plugin::Descriptor::SubPluginFeatures::Key const in various places
so we can use ConstIterator everywhere when iterating through
Plugin::DescriptorList.
All of the GUI code of EffectSelectDialog has been replaced by an
according UI file. Also merged EffectListWidget class into
EffectSelectDialog to further simplify logic.
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.
If a certain step was set for a model, the fitted value (i.e. value
divided by step, rounded and multiplied with step again) could become
smaller than minValue or greater than maxValue. Therefore explicitely
check those cases after performing the described calculation.
Closes#2840202.
One can filter resource types now using the combobox. It's also possible
to pass a certain ResourceItem::Type to the QuickLoadDialog constructor
so the according type is preselected.
All UI files are now located in src/gui/Forms and have been renamed.
Old classes using some of the forms (AboutDialog, ExportProjectDialog)
have been adapted to instantiate Ui::* instead of inheriting from it.
Added an item(QModelIndex) method to RecentResourceListModel which
maps given QModelIndex to source model and returns the according
ResourceItem from the source model.
The new WelcomeScreen widget is intended to be shown after startup
by default. It allows the user to choose how to start the session,
i.e. shows a list of recently edited projects, a list of new stuff
at the Sharing Platform as well as some help related information and
links.
Pointers to individual ResourceDBs can be obtained from Engine now.
This allows for more specialized views and reduces complexity when
dealing with resources.
So far all subclasses implemented filtering on their own which doesn't
make much sense. Now one can set filter keywords and a filter type for
all ResourceModels. Subclasses simply have to call
ResourceModel::itemMatchesFilter( ResourceItem ) in order to determine
whether an item should be hidden or not. Additionally they have to
implement the updateFilters() method in order to update their internal
management data each time the filters change.
Per default child processes inherit all file descriptors of their
parent process. This applied for file descriptors pointing to sound
devices as well. Reopening sound devices while e.g. a ZynAddSubFX
process was running always failed due to this "feature".
By manually setting the FD_CLOEXEC flag for the sound device file
descriptors they do not get inherited by child processes anymore.
This is an initial integration of the new QuickLoadDialog into LMMS.
One can either open up the dialog via Ctrl+L or the "Edit" menu.
The dialog is for testing only and not useful at all yet.
This commit introduces initial version of the QuickLoadDialog.
It's a simple dialog with a filter line-edit as well as a ListView
showing all (filtered) ResourceItem's. Once integrated properly it'll
allow to quickly load a specific resource into current context, e.g. a
sample into AudioFileProcessor or a MIDI file into SongEditor.
The new ResourceListModel implements a ResourceModel to be used with
QListView & friends. It provides all items of the given ResourceDB as
a flat unsorted list. It'll be mainly used for the upcoming
QuickLoadDialog.
ResourceListModel features an internal lookup table, resulting in very
good performance when filtering (even with thousands of items).
Place functionality to where it belongs. ResourceItem::matchKeywords()
now returns whether a given list of strings matches with various
string properties of the item.
The new generic ItemRelation template class replaces ResourceTreeItem's,
resulting in cleaner and better organized code.
In the future other kind of items can be linked hierarchically using
the ItemRelation template.
