This can happen when a device is already connected
while Arodur is stating. The butler thread may activate it
(immediately post-engine), while the GUI thread tries
to do the same later when restoring state.
* reserve "probe" to actually probe for devices
* use separate probe for libusb and MIDI port devices
* use "available" to check if surface can be used
* allow both methods to be NULL
* remove unused ControlProtocolDescriptor* argument
Most surface just return `true` for available.
In case of internal backends this allows to retrieve the
Device name for a given (hashed unique) port-name.
As opposed to "pretty-name" (which defaults to hw-port-name),
this cannot be changed by the user.
It is intended to be used when probing for control surfaces.
In case there are any unconnected tracks, the track's output is
assumed to align to the master bus (see Route::update_signal_latency).
For this to work correctly the master bus port's public latency
has to be set first.
This fixes e.g. the following issue: add a latent plugin to
the monitor section. Then toggle its bypass or remove it.
Previously the worst-case latency remained unchanged.
VST3PI::performEdit already updates the shadow data, so
since 979f9876a7
VST3Plugin::set_parameter effectively did nothing (unless a user
rapidly moves the control slider, in which case the next process
cycle sets a previous value).
~Session calls AudioEngine::remove_session(), which fades out,
then unsets the session, and then in libs/ardour/audioengine.cc:460
```
session_removed.signal(); // wakes up thread that initiated session removal
```
Session d'tor continues, and calls Port::PortDrop(), which
unregisters all ports one at a time.
Concurrently, AudioEngine continues, and calls PortManager::silence_outputs
which gets all ports first (!), and then iterates over them.
There is a race condition which can lead to
DummyAudioBackend::get_buffer: Assertion `valid_port (port)' failed
This fixes a "too many sections" issue
```
Fatal error: can't write 159 bytes to section .text of build/libs/ardour/luabindings.cc.1.o: 'file too big'
x86_64-w64-mingw32-as: build/libs/ardour/luabindings.cc.1.o: too many sections (36781)
```
This also mitigates an issue that selecting a track in
a group may select other tracks. Previously the last
selected track's input was connected to MIDI ports, which
is usually not the track that the user clicked on.
There is no need to preallocate request buffers for these threads - the event
loops that require them can allocate them when they discover and register the
pre-registered threads. This also means that event loops do not need to
register request buffer factories.
The old code assumed that the thread that created a request buffer for a given
signal-emitting thread would be the latter thread, and thus a thread-local
pointer to the request buffer could be used. This turns out not to be true: the
GUI thread tends to be responsible for constructing the request buffers for
pre-registered threads.
That mechanism has been replaced by using a RWLock protected map using
pthread_t as the key and the request buffer as the value. This allows any
thread to create and register the request buffers used between any other pair
of threads (because the lookup always uses a pthread_t).
The symptoms of this problem were a signal emitted in an audioengine thread
that was propagated to the target thread, but when the target thread scans its
request buffers for requests, it finds nothing (because it didn't know about
the request buffer). In a sense, the signal was successfully delivered to the
target thread, but no meaningful work (i.e the signal handler) is performed.
Because we use the non-callback API, we can call our thread init callback
ourselves from ::process_thread(). In addition, the init_callback in JACK is
used by every thread JACK creates, including the messagebuffer thread, and this
confuses things from an Ardour POV where the callback was intended just for
realtime threads.
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
```
