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...
Fixes#865. Added a check so we don't add subnotes to a note that is already released (can happen with very short midinotes, eg. sliding the mouse accross the gui piano).
I also added a mutex to incoming midievent handling in instrumenttrack. Not sure if strictly necessary, but seems like this would prevent problems in the long run.
Also fixed a glitch in noteplayhandle where silent master notes got stuck playing indefinitely ( isMasternote() returns true even if the nph just hadChildren, so it never gets ended if it did - instead we check if we still have subnotes).
- currently only affects Vestige
- no idea whether this can also be used for Zyn and OpulenZ, I'm not sure if Zyn has any kind of mechanism for communicating frame offset to the synth, as for OpulenZ, @softrabbit would know the answer better
- basically, I made it happen by simply adding an extra parameter in the processMidi{In|Out} functions, which is 0 by default, and made the necessary changes in instrumentTrack and nph to utilize it
- I based this against 1.1 because I didn't think it's a very big change, and I don't see much possibility for things going wrong here, since we're basically just using the existing functionality in Vestige (there already was a frame offset being communicated to the remote plugin, just that it was always set to 0). However, if @tobydox thinks this is better to bump up to 1.2, I can rebase it for master...
Instead of having various flags for realizing the arpeggion functionality
use a more generic approach here using the recently introduced "origin"
property.
This does not work well if you open an instrument window of a single
streamed instrument, close it afterwards and open an instrument window
of a regular instrument due to widget caching/reuse. We therefore have
to find a better solution which allows dynamically showing/hiding tabs
in the TabWidget class. Until then restore the previous behaviour.
This reverts commit ed29f2b6f6.
In order to keep compatibility with projects created with LMMS < 1.0.0
we maintain a property specifying the base velocity (i.e. the velocity
sent to MIDI-based instruments at volume=100%). For new projects this
always will be 64 while compat code enforces a value of 127 for old
projects.
We can also think about hiding the new groupbox in order to hide
complexity from the user.
Closes#430.
There'll be more and more flags for instruments. Handling them using
virtual and overloaded getter functions doesn't scale well and adds
unneccessary overhead.
Since addition of automation, controllers etc. the freeze functionality
has been rather broken and thus adds no value anymore. In order to not
confuse users with broken functionality, remove it at all.
Closes#345.
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.
As of commit 1266278229 silent buffers
from InstrumentPlayHandle-driven instruments are ignored. This is a good
thing but can beak PeakController instances attached to e.g. ZynAddSubFX.
Fixes playback of unfa-Spoken.mmpz.
InstrumentPlayHandle-driven instruments (i.e. instruments producing only
one sound stream for all notes) are running all the time even if no notes
are running. The plugin itself usually does not consume much CPU time
while silent but all effects afterwards inside LMMS unneccessarily
consume lots of CPU time for processing silent buffer.
Typical case: a song with lots of instruments like ZynAddSubFX.
With this change, all processing is skipped on silent buffers which
notably decreases CPU load for many projects. All effects in following
effect chains continue to run until they're silent as well.
Closes#267.
As the pitch range model defines the range of the pitch model we have
to load it first so the range of m_pitchModel gets adjusted accordingly.
Closes#272.
Next big coding style update - this time all PlayHandle classes are
affected. Functions like done() and released() were renamed to
isFinished() and isReleased().
Even though there are probably not many old projects out there, at least
old presets didn't load properly anymore as of ad27039b9b.
Fix this by reintroducing compat code.
We must not record notes when receiving external MidiNoteOff events
as e.g. the sustain pedal still might be pressed. State tracking for
features like these is done inside NotePlayHandle so move the recording-
related signal emission from InstrumentTrack to NotePlayHandle.
Closes#168.
We should not need compat code for project files < 0.4.x anymore.
Anybody who wants to load project files made before 2008 is advised to
open them in LMMS 0.4.x first and save them so they get upgraded.
When changing the pitch range all we can do for MIDI is to update the
MIDI pitch bend sensitivity RPN even though this is only supported by
some MIDI instruments.
Closes#129.
If we receive MidiNoteOn, MidiNoteOff or MidiKeyPressure events we always
kind of handle them in processInEvent() so do not forward them to the
instrument.
This fixes a freeze when loading VST plugins as PianoView::focusOutEvent()
tried to send MIDI events to the not yet completely loaded and thus locked
VST plugin.
Closes#160.
There are situations where processOutEvent() is being called while
loading instrument track settings e.g. when loading the pitch model
whose dataChanged() signal is connected to InstrumentTrack::updatePitch()
which in turn calls processOutEvent(). At this time we do not have an
instrument instance and therefore have to skip processing.
Closes#164.
As processInEvent() is responsible for starting/stopping notes, we do
not have to set the state of the piano. This is done in processOutEvents()
already.
The MIDI event handling in InstrumentTrack was complex and buggy. It has
been simplified now such that processInEvent() tries to handle note on,
note off and key pressure events. The actions taken should result in
equivalent calls to processOutEvent() by NotePlayHandle instances. The
processOutEvent() function sends according MIDI events to the attached
instruments. All unhandled MIDI events are directly forwarded to the
instrument in processInEvent().
It's possible that some corner-cases are not handled yet with the new code
and we have regressions now.
Furthermore renamed midiTime/midiEvent to MidiTime/MidiEvent to match
coding style.
Closes#72.
Arpeggiator got InstrumentFunctionArpeggio and ChordCreator got
InstrumentFunctionNoteStacking. All related views and instances have
been renamed for better consistency.
Vesa