This fixes a crash in some plugins (e.g. Auburn Sounds Couture)
when disconnecting all inputs (e.g. moved before a synth).
Previously run was called with numChannels = 0
Even though the plugin refused to be configured that way.
* during drag and trim operations, we use "dragging region" transparency
so you can see the audio data beneath your region(s)
* we already do this for region-end-trim fade drags, which is a special
kind of trim operation, accessed from the 'lower' drag handle
* now we also trigger transparency for regular fade trims.
see discussion at:
https://discourse.ardour.org/t/regions-transparency-in-7-2/108060/31
This enables all channels left of the last connected pin
for each given bus. e.g. when using just the 2nd (right)
input of a given bus, the plugin is configure in stereo
mode, with the 1st (left) input being fed with silence.
VST3 does not have a "right-channel mono" configuration.
It is also preferable to have Ardour do the pin/channel
mapping.
This fixes an issue with recent JUCE when using a stereo
plugin on a mono track.
`juce::validateLayouts` requires that numChnanels matches
the configured channel-mapping:
69795dc8e5/modules/juce_audio_processors/format_types/juce_VST3Common.h (L630)
JUCE could be more liberal and accept
`(int) mapIterator->size() > it->numChannels`
Previously that caused an assert() in audio_clock.cc:1964
current_duration(): Assertion `is_duration' failed.
Optimized builds always returned zero duration.
This code presumably intended to name sources "foo%a", "foo%b" etc, but
since it was incorrectly appending the character as an integer sources
instead ended up being named "foo%97", "foo%98" etc.
Also changes the branching logic to use this branch upto 26 channels,
rather than just upto 25 channels, as that seems to have been the
intention.
This is relevant when bouncing track -> track -> n/c.
It also helps to balance send latency route [send to bus] -> n/c
when the bus is connected to master or outputs.
This undoes edd68d8682, "ExistingMaterial" worked IFF
the click playback was exactly 1 cycle delayed and the
disk-writer _playback_offset was set to 1 cycle.
Now that audio buffers are flushed (see prev commit), the
click I/O's output is directly available and CaptureTime
is the correct alignment (as it always was).
Forward data for ports that are both internally and
externally connected.
e.g. click-io may be connected to a track as well as physical
outputs. Since the port is externally connected, data is written
to an internal buffer _data[], and only at cycle-end resampled
to engine-buffers.
However a track's recording the metronome is not externally
connected. Hence data is directly read from the engine-buffers.
Summing also happens at engine level, so data has to
be written back for downstream ports to read them in the same cycle.
* Fix reset on timeout: Reset needs to be called before
processing any messages.
* use DLL to compute BPM (remove 1st order LPF)
* set BPM before calculating ppqn
* Fix speed at 1.0, change BPM only. MIDI clock must
vari-speed (which changes pitch). MIDI clock is acts as
"Conductor" that specifies when a beat happens at a given
wall-clock time. timecode moves at speed 1.0 only the BPM
changes.
