Not all plugins save current program in their chunk (or do not restore
it properly). We therefore have to save and restore the current program
manually.
Closes#3581879.
The code for managing programs/presets of RemotePlugin instances was
very confusing, mainly within the VstPlugin and RemoteVstPlugin class.
I therefore started to reorganize and rewrite functions.
This patch adds the option to remove the extra silence at the end,
so that the exported song can be seamlessly looped.
This is a backport of commit 8f1657164a.
Closes#3588890.
Signed-off-by: Tobias Doerffel <tobias.doerffel@gmail.com>
We have to use the new semantics of the ProjectRenderer management when
exporting the whole project as one track as well. Otherwise the program
crashed as it tried to utilize the ProjectRenderer instance twice.
Due to various bug reports, I think we should turn off auto save per
default. Users who want this feature can turn it on explicitely (and
live with problems when they have big projects).
We have too many components in LMMS relying on FFTW3. Building LMMS
without them cripples LMMS' functionality substantially, so simply
make fftw3 a requirement.
Closes#3495736.
It came to me that having LMMS output one fixed note from a track could
be useful for controlling drum machines or something like that, so here's
a new spinbox for the MIDI tab.
Signed-off-by: Tobias Doerffel <tobias.doerffel@gmail.com>
Here is the patchset for my multiple track export feature. It works now
the way I originally envisioned.
For example, after I export tracks on my little song, I see this in the
directory I created:
devin@devin-studio:~/lmms/projects/fff$ ls
0_Defaultpreset.wav 3_Defaultpreset.wav 6_csidSouwav.wav
1_Defaultpreset.wav 4_spacenoiseswavwav.wav 7_HHOPENwav.wav
2_Defaultpreset.wav 5_csidkickwav.wav 8_HHOPENwav.wav
Each instrument or sample track is exported individually, regardless of
whether in its own song track or playing as part of a BB track. The
name is taken from either the song track name or from the BB track name.
My goal was to get the tracks individually exported, so that I could
combine them with other tracks in Ardour.
Signed-off-by: Tobias Doerffel <tobias.doerffel@gmail.com>
Here's one way to cram more stuff onto small screens, or otherwise help
reducing visual clutter: Allow tracks to be shift-dragged all the way
down to 8 px height.
Signed-off-by: Tobias Doerffel <tobias.doerffel@gmail.com>
This patch includes:
* sampleBuffer::visualise(): add possibility to specified a range to visualize instead of the whole sample
* add sampleBuffer::sampleRate() and sampleBuffer::sampleLength() getters
* definition of AudioFileProcessorWaveView and AudioFileProcessorWaveView::knob classes for AudioFileProcessor plugin
* knob::getValue() specified “virtual” to allow redefinition in child class AudioFileProcessorWaveView::knob
* delete audioFileKnob class (made obsolete by AudioFileProcessorWaveView::knob)
* add audioFileProcessor::isPlaying() signal, which is emitted in audioFileProcessor::playNote
* change type of AudioFileProcessorView::m_startKnob and AudioFileProcessorView::m_endKnob (AudioFileProcessorWaveView::knob instead of audioFileKnob)
* replace AudioFileProcessorView::m_graph (QPixmap) by AudioFileProcessorView::m_waveView (AudioFileProcessorWaveView)
Signed-off-by: Tobias Doerffel <tobias.doerffel@gmail.com>
A break was missing in the function where MIDI events are generated from
raw MIDI data. This always has been broken as of commit d188056683
but was not observed as the code for all switch-cases has been identical.
The problem comes from AutomatableModel::m_initValue wich is not fitted
either in constructor or in setter. Idem for m_value in constructor, imo
this is not enough consistent.
I propose to:
- call fittedValue() in init value setter.
- always call setter to initialize current & init values.
Upstream commit 460642bfae534679b4094e6887714828c90d8172 removes LADSPA
support from CALF which definitely is not desired for LMMS. Therefore
simply revert it in our sources.
When building LMMS with recent stable versions of GCC it generates
wrong code for the implicit REALTYPE specialization of the template
method stringFrom<T>() (problem in std::stringstream implementation).
By writing a custom template specialization which uses sprintf() the
bug can be circumvented.
