* ThreadableJob: Move from AtomicInt to std::atomic
This is the first in a series of commits that migrates away from
AtomicInt towards the C++11 standard library types.
This would allow the removal of AtomicInt and related Qt
version-specific code.
While we're at it, also make ProcessingState an `enum class` so that
it's not implicitly convertible to integers.
* LocklessAllocator: Switch from AtomicInt to std::atomic_int
If it looks like some assignments around the Compare & Swap loops went
missing, it's because compare_exchange_weak() updates the first argument
to the current value when it fails (i.e., returns false).
* BufferManager: Remove extra AtomicInt include
* MixerWorkerThread: AtomicInt to std::atomic_int
* NotePlayHandle: AtomicInt to std::atomic_int
* Remove AtomicInt.h
* Move from QAtomicPointer to std::atomic<T*>
This removes some #ifdef trickery that was being used to get
load-acquire and store-release from Qt5 and "plain" (presumably
sequentially-consistent) loads and stores from Qt4.
* Use owning types when possible.
Note: the QByteArray s is detached to mimic previous behavior;
detach() guarantees that the QByteArray uniquely owns its data, since
otherwise it's COW. This may be relevant in case Plugin:instantiate
modifies s.data() -- this way the original QString is safe.
* Make m_filter a unique_ptr.
* Make m_activeRenderer a unique_ptr
* use std::string instead of strcpy + buffers
The methods NotePlayHandle::index and NotePlayHandle::nphsOfInstrumentTrack
had not yet been brought up-to-date with the new system of attaching child
NotePlayHandles directly to the mixer. This caused strange glitches when
arpeggio was used in sort mode.
- 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
Change in handling of frameoffset for multistreamed instruments and sampletracks.
- Instead of holding the offset for the lifetime of the playhandle, negate the offset in the first period
- Multistream-instruments require some small changes: they have to now check for the offset and accordingly leave empty space in the start of the period (already done in this commit)
- There are possibly optimizations that can be done later
- This change is necessary so that we can have sample-exact models, and sample-exact vol/pan knobs for all instruments. Earlier multistream instruments were always rendering some frames ahead-of-time, so applying sample-exact data for them would have been impossible, since we don't have the future-values yet...
Instead of having various flags for realizing the arpeggion functionality
use a more generic approach here using the recently introduced "origin"
property.
The volume of an InstrumentTrack is applied separately when post-processing
the audio buffer and is not related to MIDI processing. It therefore should
not be included into MIDI velocity calculation.
Closes#301.
Next big coding style update - this time all PlayHandle classes are
affected. Functions like done() and released() were renamed to
isFinished() and isReleased().
