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.
The RemoteVstPlugin process crashed for plugins with lots of presets
as there was an overflow of the presName buffer. Chosing a bigger buffer
size fixes the problem.
Additionally initialize len variable in loadChunkFromPresetFile().
Added an option to shrink the track buttons horizontally, mainly by
moving the track name into a tooltip.
Closes#3459241.
Signed-off-by: Tobias Doerffel <tobias.doerffel@gmail.com>
By Mikobuntu:
I have created a patch ( tested on stable) that adds a metadata entry
"Software" with the value "LMMS (libsndfile-1.0.21)" I'm not quite sure
what calls in the libsndfile entry as my only field entered was LMMS,
but i guess it does no harm anyway to know ;)
Closes#3374272.
Signed-off-by: Tobias Doerffel <tobias.doerffel@gmail.com>
If the settings for an AutomationPattern contain just one value at
position 0, this value was not loaded properly. Thanks to raine for
pointing out this issue and providing a patch.
Closes#3448562.
When freezing patterns the freezer hung forever as it checked for any
running play handles in order to render echoes etc. after the last note.
However if there are MIDI-based instruments such as LB302, ZASF,
Sf2Player etc. there will always be play handles (InstrumentPlayHandles)
in the mixer's play handle array. Therefore explicitely check for
remaining NotePlayHandles when freezing pattern. Furthermore added a
counter variable for safety reasons so rendering note tails will never
exceed 2000 buffer periods.
Thanks to Mikobuntu for reporting this issue!
Closes#3109262.
Note detuning did not work properly for patterns starting after the
first bar in the song editor. This has been fixed by introducing
additional information about parent's song-global offset to
NotePlayHandle objects.
Closes#3462555.
