New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LMMS Memory Manager #1088
LMMS Memory Manager #1088
Commits on Nov 18, 2014
-
-
-
-
Add dedicated manager for noteplayhandles
This caches and reuses nph's independently of the generic memory manager.
-
Changing and fixing some stuff
- 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
-
-
Fix arpeggio to work better with the new way to handle note offsets
Ok, not really related to memory management, but was something that needed doing and it's easier to test things when things work properly
-
-
-
Use memory management in LADSPA effects
Also optimize non-inplacebroken plugins by using the same buffer for input/output
-
Make it possible to use sample-exact controls in LADSPA plugins
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...
-
Also, apply things learned while writing BufferManager to the similar NotePlayHandleManager
-
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.
-
Finish audioport rehaul, get vol/pan knobs working again, also some b…
…ugfixes We're now doing the vol/pan stuff in audioport, since this way we avoid the pointless repetition of doing it in the playhandles
-
-
Initialize BufferManager from within Mixer
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.
-
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
-
-
-
-
-
-
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