* docs: fix update libstk0-dev to libstk-dev for debian/ubuntu
* docs: Fix STK installation message in CMakeLists.txt
* docs: STK installation message in CMakeLists.txt to include both libstk-dev and libstk0-dev
* docs: update wiki submodule version to latest
When #8169 was merged, the resize grip of clips was increased to 8 pixels to make it easier to resize clips which were right next to each other. However, this constant 8 pixel region on either end of the clip gets in the way when zoomed far out, since the width of the clip itself could be on the order of 8 pixels.
To fix this, this PR makes it so that the clip resize grip width dynamically changes with the zoom level. When zoomed far in, it's 8 pixels, but as you zoom out, the grip width is capped to be no more than 10% of the clip width. This makes it much easier to move the clip around without it getting in the way.
Fixes#8384
Bugs fixed:
1. Doubled tooltips on some Knobs (see #8358)
2. No dynamic floating text when dragging a Fader (regression from #8253)
3. Volume knobs displaying their units as "dBFS%" rather than just "dBFS" (regression from #8253)
4. Incorrect dBFS value in the dynamic floating text for volume knobs of the Delay and Flanger plugins
5. Incorrect dBFS values in the "Set value" dialog box for volume knobs of the Delay, Dynamics Processor, Flanger, and Wave Shaper plugins
6. Missing "%" unit in the context menu for Vibed's volume knobs
7. Incorrect handling of volume knobs for models that support negative amplitudes (currently only Flanger's feedback amount knob)
For (1), I reworked how static tooltips work in FloatModelEditorBase. Rather than use QWidget's tooltips, it shadows the tooltip methods from QWidget and redirects them to the existing SimpleTextFloat-based system.
Supporting both "static" and "dynamic" tooltips required some improvements to keep better track of user interactions with the Knobs. There was an existing m_buttonPressed boolean, but this was insufficient, so I converted it into a new InteractionType enum for keeping track of the user interaction state.
See the "Expected Behaviour" section of the bug report (#8358) for an explanation of how it works now from the user's perspective.
Allows playback of a sample clip in the pattern editor to start at any position and not only at t=0 as it is currently the case. This also ensures that the sample is played each loop, which is currently very inconsistent.
---------
Co-authored-by: bratpeki <pkatic2003@gmail.com>
Co-authored-by: Yohanan <23298480+yohannd1@users.noreply.github.com>
It takes a bit of time for this pitch shifter to "warm up" and get all of its grains spawned (as is the nature of all granular audio processing), so it's best to start flushing some audio through immediately upon plugin initialization or sample rate change.
Essentially the same fix as #8385, but for notes in the Piano Roll.
This PR makes it so that the clip resize grip width of a note dynamically changes with the zoom level. When zoomed far in, it's a constant number of pixels, but as you zoom out, the grip width is capped to be no more than 25% of the note width. This makes it much easier to move the note around without it if it's tiny or when zoomed far out.
Previously, importing midi files containing multiple tracks was not supported. All of the notes got merged onto a single track.
Except, LMMS actually does support multi-track midi import, it just ignores the track index when placing the notes, and simply puts them in tracks based on their midi channel instead. LMMS does not support setting the channel of an individual note, so separating the loaded midi events onto separate tracks based on their channel does make sense.
But we don't have to choose one or the other! This PR makes it so that the notes in midi files are split into different tracks based on both their midi channel and midi track. This allows midi files which contain multiple tracks to be loaded normally, and hopefully even multi-channel multi-track midi files.
Additionally, some midi files contain a wealth of information regarding midi CC automation. Currently, we only handle pitch, panning, volume, and bank automation when importing midi files, but this PR also makes it so that the knobs in the instrument track CC rack are also automated.
NOTE: Regarding the CC automations, some CC numbers correspond to things like panning and volume, which are real knobs in lmms. In the case that one of these CC's are automated, it creates an automation track for that specific lmms knob. Otherwise, it automates the knob in the instrument track's midi CC rack.
TLDR: Normally, the AutomationClip containing the detuning curve of a Note is created for every single note, no matter if it actually has detuning or not. This PR changes that so it is only created when the user edits the detuning.
When #7477 and later #7888 were merged, they reworked how Note objects were copied to prevent two different notes from sharing the same detuning automation curve, which would mean editing one's detuning would edit the other's at the same time.
This made the workflow more correct, but it came at the cost of performance. Unfortunately, every single Note object had to have a DetuningHelper object which contained an AutomationClip. These AutomationClips are complex QObjects with signals and slots and models inside them, which is not great when you need to copy a whole bunch of notes at once.
Ideally, I think we could replace the detuning clip with something simpler than an automation clip; something which only holds the bare minimum curve data. But that is for a later time; this PR uses a different solution.
Detuning automation clips are only needed by the Note if the user has added any pitch bending. But for the vast majority of notes, there is no pitch bending, so they do not really need the detuning clip. Currently, the detuning object is initialized right when the Note is created. However, this can be changed so that it is only created when the user decided to edit the detuning. This saves an enormous amount of processing when copying notes.
This technically means that there is the possibility that note->detuning() could be nullptr. However, I went through all of the occurances in the codebase, and I added checks where there was the potential it could be nullptr.
* Fixed key inputs not updating the time display in Song-Editor
* Fixed the 'Home' button updating the time display in Piano-Roll
---------
Co-authored-by: bratpeki <pkatic2003@gmail.com>
Co-authored-by: regulus79 <117475203+regulus79@users.noreply.github.com>
* Prevent key modifiers from getting stuck
* Implement a custom isWinDeactivate function to assist in detection
---------
Co-authored-by: Dalton Messmer <messmer.dalton@gmail.com>
Fixes a bug where right-clicking on a sample in the sidebar and clicking "Send to new SlicerT instance" under the Pattern Editor section would instead create the instance in the Song Editor.
This PR makes it so that the scale/key/chord in the Piano Roll is saved with the project.
Also, while I was at it, I made it so that the zoom, vertical zoom, snap settings, quantization, and note lengths are saved too.
Aaand I also decided to save the zoom and snap size in the Song Editor because why not :D
However, the zoom/snap/etc are saved in the lmmsrc file, since it doesn't really make sense to save them per-project.
Makes the following changes to the Lb302 plugin for increased functionality, maintainability, and readability:
- Add note velocity & note panning to Lb302
- Remove evil mutex+dynamic array combo in favor of a real-time safe ringbuffer queue
- Use non-static data member initializers where possible
- Use `std::numbers::pi` instead of `M_PI`
- Use `std::array` and `std::unique_ptr` instead of manual memory management
- Change plain-old-data classes with only public members to structs
- Change some ints to f_cnt_t to better communicate their purpose and avoid weird implicit casting nonsense
- Change floats to sample_t where appropriate to better communicate their purpose
- Find suitable homes for loose constants
- Prefix standard library math function calls with std::
- Ensure all floating-point literals intended to be floats end in 'f' and are not doubles to appease MSVC
- Change uses of SIGNAL and SLOT macros to whatever they should be post-Qt6 upgrade
- Tidy code to conform to current code conventions
Also adds Hardware.h for low-level performance tools:
- busyWaitHint(), supporting x86, ARM, and RISC-V
- hardware_destructive_interference_size polyfill, supporting x86, ARM, RISC-V, and PPC
- Moved the contents of denormals.h to Hardware.h, renamed disable_denormals() to disableDenormals()
- Added ARM support to disableDenormals()
* Adds a new native plugin for incoming waveform display
* Features the ability to pause, zoom in, set window size and set amplification (scale)
* Does not feature a pitch-tracking option
---------
Co-authored-by: Fawn <rubiefawn@gmail.com>
Co-authored-by: Sotonye Atemie <satemiej@gmail.com>
Co-authored-by: Dalton Messmer <messmer.dalton@gmail.com>
Co-authored-by: bratpeki <pkatic2003@gmail.com>
Removes construction of the unused default volume model from `SamplePlayHandle`. Frequent construction of this model was causing performance slowdowns due to the model having to find and create a journaling ID in a for loop inside `ProjectJournal::allocID`, leading to the exhaustion of available IDs very quickly. There were also general improvements made to `SamplePlayHandle` (using NSDMI, removing other unused members, etc).
Adds a check in finishRecordNote that verifies no notes of length 0 can be made, which was possible before.
---------
Co-authored-by: bratpeki <pkatic2003@gmail.com>
Migrates all MinGW 3rd-party dependencies to vcpkg except for Qt and libgig.
This enables the following for MinGW builds
- mp3/opus support
- per-note panning in Sf2 Player
- DirectSound and WASAPI audio backends in PortAudio
- LV2 plugin support
Opening the Settings would unconditionally try to start the JACK server
if it was not already running, even if the user was using an audio
backend other than JACK. When it failed to start the JACK server, it
would retry a few times which made opening the Settings take several
seconds. For me, it also broke my whole system's audio, requiring me
to restart pipewire.
This PR fixes that problem by passing the JackNoStartServer option to
jack_client_open() in the setupWidget used by the Settings.
AudioJack::initJackClient() continues to use the JackNullOption option,
so like before, it will still attempt to start the JACK server if you select
the JACK backend and restart LMMS.
I also moved some static free functions into a nearby anonymous
namespace, and I removed the server name argument from the
jack_client_open() calls since that variadic argument is only supposed
to be passed if the JackServerName option is passed.
Improves the tap tempo algorithm and usage, as well refactoring the code for better maintainability.
---------
Co-authored-by: Dalton Messmer <messmer.dalton@gmail.com>
This reworks the auto-quit feature by introducing a new AudioBuffer class which keeps track of which channels are currently silent as audio flows through the effects chain.
When track channels going into an effect's input are not marked as quiet, it is assumed a signal is present and the plugin needs to wake up if it is asleep due to auto-quit. After a plugin processes a buffer, the silence status is updated.
When the auto-quit setting is disabled (that is, when effects are always kept running), effects are always assumed to have input noise (a non-quiet signal present at the plugin inputs), which should result in the same behavior as before.
Benefits:
- The auto-quit system now closely follows how it is supposed to function by only waking plugins which have non-zero input rather than waking all plugins at once whenever an instrument plays a note or a sample track plays. This granularity better fits multi-channel plugins and pin connector routing where not all plugin inputs are connected to the same track channels. This means a sleeping plugin whose inputs are connected to channels 3/4 would not need to wake up if a signal is only present on channels 1/2.
- Silencing channels that are already known to be silent is a no-op
- Calculating the absolute peak sample value for a channel already known to be silent is a no-op
- The silence flags also could be useful for other purposes, such as adding visual indicators to represent how audio signals flow in and out of each plugin
- With a little more work, auto-quit could be enabled/disabled for plugins on an individual basis
- With a little more work, auto-quit could be implemented for instrument plugins
- AudioBuffer can be used with SharedMemory
- AudioBuffer could be used in plugins for their buffers
This new system works so long as the silence flags for each channel remain valid at each point along the effect chain. Modifying the buffers without an accompanying update of the silence flags could violate assumptions. Through unit tests, the correct functioning of AudioBuffer itself can be validated, but its usage in AudioBusHandle, Mixer, and a few other places where track channels are handled will need to be done with care.
---------
Co-authored-by: Sotonye Atemie <sakertooth@gmail.com>
Allows detaching a window from LMMS's main window, making things like working on multiple screens easier.
The behavior of detached windows can be customized in the Settings.
Closes#1259
---------
Signed-off-by: Dalton Messmer <messmer.dalton@gmail.com>
Co-authored-by: Hyunjin Song <tteu.ingog@gmail.com>
Co-authored-by: Dalton Messmer <messmer.dalton@gmail.com>
Co-authored-by: SpomJ <mihail_a_m@mail.ru>
Improves performance when moving mixer channels to the left or right using simple Qt layout operations and swapping of values. This commit also addresses a deadlock in Mixer::mixToChannel by ensuring we lock and unlock the same channel regardless of any move operations occurring simultaneously on another thread.
