This also fixes the channel-count use by the bus,
depending on the type (aux or direct out).
Mixbus detection is also moved from the GUI to the
backend.
This also limits the number of subgroup busses to one,
so that "Remove subgroup bus" works properly.
Eventually we should allow multiple subgroup busses
for aux-sends.
Previously, the PT import would place regions on tracks
numbered from 0, therefore landing on unrelated tracks
when pre-existing tracks were present in the session.
This change skips all existing ardour tracks and imports
the PT regions onto the correctly named, appended tracks.
If any tracks exist with the same names as the ones in the import,
the new tracks get an incremented number at the end of them and
the imported regions are placed on the new track, as expected.
RCU reader returns a shared ptr to the current object which
can also be used in other places at the same time.
Sorting the shared-ptr list invalidates iterators which can
throw off other users of the same object.
This fixes a bug in PT-import which calls get_nth_audio_track().
This reduces initial parameter-changes during session-load
due to Controllable (PluginControl) state restore after
restoring the plugin state. This likely fixes#9287
This fixes some edge-cases when scanning recent sessions
in get_state_files_in_directory() and likely some other
places that use run_functor_for_paths in case the folder
contains files with non UTF-8 names.
This lead to potentially silent stem-exports. It
should not be possible to hold a shared-ptr reference
of a processor that is not part of the processor chain.
When toggling a channel-configs the following happens:
1. TrackExportChannelSelector::update_config
2. ExportProfileManager::clear_channel_configs
3. RouteExportChannel::create_from_route
[...] CriticalSelectionChanged
4. ExportDialog::update_warnings_and_example_filename
5. ARDOUR::ExportProfileManager::get_warnings
6. ARDOUR::ExportProfileManager::build_filenames
7. ARDOUR::ExportFilename::set_channel_config
[...]
Step 3 creates a RouteExportChannel, Step 7 retains a
shared-pointer to it in the config's ExportFilenamePtr.
When toggling another channel: step 2 release the reference
and step 3 creates a new RouteExportChannel.
This new channel reuses the existing Route::_capture_processor (!).
Now Step 7 releases the first RouteExportChannel in order
to get_warnings for the new one. Since ExportFilenamePtr holds the
the last reference, the d'tor of RouteExportChannel runs,
which removes the capture-processor from the route.
The newly created RouteExportChannel now has a reference
to a CaptureProcessor that is not in the signal-flow.
Note: the order of adding/removing RouteExportChannel matters.
With a two track session:
* Disable "with track/bus processing
* Enable Track 1
* Enable Track 2
* Disable Track 1
* Enable Track 1 // << Track 2 becomes silent
When a control-point is exactly at tick (N * 8), iterating
over the List (Sequence<Time>::const_iterator::operator++)
skipped the point.
Sequence::time_between_interpolated_controller_outputs == 8.
This reverts commit 37cae2f971.
This changes causes issues with recursive calls to the enter/leave event handling
stacks in gtk2_adour. Semantically, the change makes perfect sense, but finding
a solution to the recursion is challenging.
This is better provided by Plugin::print_parameter, which
is called by PluginControl::get_user_string(). This removes
special cases for the mode enums.
Disambiguate export formats with different encoder
qualities, sample-formats or settings (wav/bwav).
This allows to export multipe mp3 with different bitrates.
When multiple child processes are running, closing the
stdin of one child did not send EOF or cause POLLNVAL,
as long as a dup()'ed filedes still existed.
This fixes an issue when running an mp3 encoder while the
video monitor is visible, and will allow to concurrently
run multiple mp3 encoders or other child processes.
Previously this caused Ardour to hang indefinitely in CmdPipeWriter
```
_proc->close_stdin();
_proc->wait(); // << here
```
This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
This fixes an issue when changing port-configuration
or toggle strict-i/o of latent multi-out plugins.
`Session::auto_connect_thread_run` can run concurrently
while ports are added/removed from the GUI thread.
The latter invalidates IO::_port PortSet, while
the former thread iterates over ports.
This also changes the IO-Mutex into a RWLock to allow
concurrent access when possible.
Due to rounding (r->position_sample() - start.samples())
can become negative even if (r->position () >= start).
with k = start_division and start_division < 0 this
caused an invalid vector access `layers[j-1][k]`.
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.
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`
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.
* Honor MCLk stop messages, do not auto-start as soon as
the tempo is locked (after 3 clock ticks).
* Retain MIDI beat position, do not rewind in ::update_midi_clock
Do not directly start when receiving the position message,
transport speed should be zero (regardless of clock speed),
until the "continue" message arrives.
* Mclk start needs to rewind (not reset)
There is still an issue with start, when
_session->transport_sample() is not zero. Ardour ends up
constantly locating, rolling for a short time and re-syncing
by locating again.
For normal cairo-widgets ardour should not use image surfaces on macOS,
because that bypasses retina scaling. In theory explicit upsampling could
be performed (compere to openGL/cairo), but for the case at hand that is
overkill and inconvenient.
Performance critical widgets that render periodically can enable openGL
backing. Casual widgets (buttons with text, knobs, sliders etc) can be
rendered directly without any significant performance penalty.
