This fixes i386 optimized builds:
```
dyld: Symbol not found: _PL_CompareValues
Referenced from: /Volumes/Ardour-6.5.86/Ardour6.app/Contents/MacOS/../lib/libnssutil3.dylib
Expected in: /Volumes/Ardour-6.5.86/Ardour6.app/Contents/MacOS/../lib/libplds4.dylib
in /Volumes/Ardour-6.5.86/Ardour6.app/Contents/MacOS/../lib/libnssutil3.dylib
```
Older compilers do not yet have fmaintrin.h. This fixes compile errors:
```
x86_functions_fma.cc:51:39: error: '_mm_fmadd_ss' was not declared in this scope
x86_functions_fma.cc:85:35: error: '_mm256_fmadd_ps' was not declared in this scope
x86_functions_fma.cc:106:35: error: '_mm256_fmadd_ps' was not declared in this scope
x86_functions_fma.cc:129:39: error: '_mm_fmadd_ss' was not declared in this scope
```
By supporting FMA extension, the number of instruction needed
for multiply accumulate to mix channels are reduced. Since,
this extension has been around since middle of 2012, more
computers have this instruction set available.
This also reverts 768d8362cd since it causes crashes
with various plugins (eg. surge.vst3).
Ardour now provides AudioBusBuffers for all audio I/O busses,
regardless of Ardour using those busses.
This fixes crashes of plugins that ignore ProcessData::numInputs
or ProcessData::numOutputs. Those plugins are expected to check
numChannels and channelBuffers for those excess channels, which are
0, NULL for unused busses.
ProcessData numInputs, numOutputs does correctly reflect actual
busses that are in-use (at most one main and one aux for each direction).
This should fix an issue with yabridge and MCompressor.
The plugin has two kMain inputs and expects ProcessData:inputs
to always have two entries, even if the second bus is explicitly
disabled.
see https://hastebin.com/ekewojiqep.txt
```
IComponent::activateBus(type = 0, dir = 0, index = 1, state = false)
data.numInputs = 1;
```
TODO: optimize (pre-allocate) if it works as expected
Apparently a user managed to remove a SC input and then
use the input's context-menu before the UI had caught up.
(PluginPinWidget::plugin_reconfigured happens during idle)
---
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 [..] PluginPinWidget::sc_input_press(_GdkEventButton*, boost::weak_ptr<ARDOUR::Port>) + 1140
This significantly speeds up loading export formats that use ffmpeg.
A single call to ::transcoder_exe() took 300-400ms on Windows.
With multiple formats using an external transcoder, showing the
export dialog could take to 2-3 sec.
Those are blank to begin with, nothing is drawn, yet they'd still be
cached.
This may happen during an initial exposure (see 1a49d7d42b),
or when deleting regions.
AudioRegionView() c'tor calls create_waves() early on
before the _height is set [1].
Now one following can happen:
1. All peak-files are present. create_waves() directly calls
create_one_wave() for each channel. They are initialized
with zero height.
But all channels are present so waves[] is populated and
a later call to set_height() corrects this
2. All peak-files are still missing. create_waves() schedules
callbacks via PeaksReady -> peaks_ready_handler()
Those callbacks arrive after set_height() was called and
the waveforms are displayed correctly.
3. Only some peak-files are present. This can happen at
rec-stop when the region is created.
create_waves() directly calls create_one_wave() for available
peaks, and schedules peaks_ready_handler() for the remainder.
The directly created waves have zero-height.
Since not all waves are ready, they are stored in tmp_waves.
waves[] remains unpopulated.
The set_height() call only ever changed the height of wave[], which
resulted in hidden waveforms, until a user manually changed the
height of the track.
[1] the height is set from
```
#1 AudioStreamView::create_region_view(boost::shared_ptr<ARDOUR::Region>, bool, bool)
#2 AudioStreamView::add_region_view_internal(boost::shared_ptr<ARDOUR::Region>, bool, bool)
#3 StreamView::add_region_view(boost::weak_ptr<ARDOUR::Region>)
...
## PBD::Signal1 Playlist::RegionAdded()
```
The file has to be flushed to disk before it can be used.
This fixes an edge case only.
Since PeaksReady() is a cross-thread signal that calls
AudioRegionView::peaks_ready_handler in the GUI thread, the
function [almost] always completed, before the GUI was woken up
to schedule a WaveView render request (which uses the peak-file).
This is needed for threaded peak-file creation. The same
nested source may be accessed multiple times concurrently
(in addition to the butler thread reading it).
This fixes Bitrunner's "filum2020" session randomly showing garbage
waveforms.
This was not a typo after all, but a way to show the gain in the
name-display, as per manual:
> In the case where Gainmode is set to position, the track name
> will show the dB value while values are changing.
This reverts commit 3290d66a43.
