* Ctrl + Left/Right moves selected notes by one bar
(Old behaviour was to move the playnote)
Closes#811
* Shift + Up/Down moves selected nodes by one semitone
(Old behaviour was to ignore the Shift key and move the viewport)
Closes#810
* Ctrl + Left/Right moves selected notes by one bar
(Old behaviour was to move the playnote)
Closes#811
* Shift + Up/Down moves selected nodes by one semitone
(Old behaviour was to ignore the Shift key and move the viewport)
Closes#810
Add treshold knob to peak controller
This causes the peak controller to react only when the measured peaks are above the set treshold
Might be useful for finetuning your sidechains
Samplebuffer: reload all samples when samplerate changes. This is because of the way LMMS uses samples: we always resample all samples t$
LadspaEffect: some safeguards for the non-inplacebroken plugins which use the same buffer for input and output. Theoretically, if some p$
FxMixer: fix effect processing in multichannel-chains
Avoid crashes caused by worker threads accessing the buffer manager
before it is initialized. Therefore initialize it from within the
Mixer constructor which has the side effect that it gets initialized
in console-only rendering mode as well.
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.
I don't think we currently have any that would support this functionality, but in case someone has a LADSPA plugin that has audiorate control ports, this allows them to be used with the new sample-exact models
Again... not strictly related to memory management, but since I was in that part of the codebase already...
- QHash is better to use than QMap in MemoryManager: faster lookups, able to reserve memory in advance
- Also: reserve memory in advance for the QVector and QHash, so we don't get needles allocs for them
- No need to do cleanup for the nph manager, as it uses the generic manager for allocs, and that already gets cleaned up
The constructor was probably the wrong place to put it, run() is definitely executed in the new thread so that's where the setting should be applied I think?
