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.
Also removed all blocks similar to
```
#if QT_VERSION >= 0x040806
filedialog.setOption( QFileDialog::DontUseCustomDirectoryIcons );
#endif
```
as this now takes place in the new subclass's constructor.
