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.
Issue: Currently, we use threads to process all PlayHandles, so there's no guarantee of the order they are processed in. This causes timing inaccuracy and jitter: notes of instruments that use both NPH's and IPH's can get randomly delayed by one entire period.
The issue is solved thusly:
- When processing an IPH, we check if the instrument is midi-based. If yes, we just process it normally (no NPH's to worry about).
- If it's not, then it also uses NPH's, so we'll have the IPH wait until all NPH's belonging to same instrument have been processed. There's some similar code in the new FX mixer, I pretty much just copied how we do it there.
Next big coding style update - this time all PlayHandle classes are
affected. Functions like done() and released() were renamed to
isFinished() and isReleased().
In order to provide smooth muting functionality (i.e. immediate proper
sound when unmuting) always render audio buffers for MIDI-based
instruments. This is more important than potentially reduced CPU usage
while muted.
Closes#69.
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.
(cherry picked from commit 6940d19969)
