The semantics are that if the user configures things to allow transport commands while
using a transport master, issuing such commands first stops using the master
Auditioner seek calls are explicitly handled by the butler,
and DR:overwrite_existing_buffers() is called explicitly
to read MIDI data for audition.
Session::non_realtime_overwrite is no longer required.
This reverts commit 6fbcf83779
and parts of 2d11667ce3.
The Auditioner is not part of the session route-list and the
auditioner route's I/O latency is never updated.
Session::process_audition() does not handle pre-roll either,
so it need to be zeroed, otherwise Route::roll skips samples.
This has lead to initial samples being skipped, IFF the
auditioner's output-port had non-zero latency.
Since private port-latencies are usually only set for routes
in the route-list, and _remaining_latency_preroll is reset
at transport-stop, this *usually* worked...
Last but not least, MIDI notes need to be resolved when seeking.
IO::latency iterates over the port-set retrieving the
private_latency_range of each port. Since it can only change
when connections and latency changes, we can instead cache the value.
This is also in preparation to allow the auditioner to override it.
DiskReader::seek() no longer fills MIDI buffers.
MIDI is now read into memory via DR:overwrite_existing_buffers()
There is still some edge-case remaining to be fixed. For
some reasons the synth does not receive initial patch/program
changes when starting auditioning.
update_custom_midnam() is usually called from the GUI or butler
thread when a LV2 plugin is instantiated, or the plugin changes
its MIDNAM. It must be exclusive with load_midnams_in_thread()
and calls from MTAV to ::maybe_use().
- add missing translations
- largely follow original message regarding punctuation, capitalization
at the beginning of sentences, trailing white space
- fix typos and other obvious mistakes
Signed-off-by: Nils Philippsen <nils@tiptoe.de>
This fixes Virtual-keyboard velocity selection when scrolling
to numbers that are not explicitly in the menu-list.
(hopefully this does not introduce some recursive signals
for other ArdourDropdowns, fingers crossed).
Since 57118c2370, plugins are re-activated after every export.
So a silent pre no-roll is mainly useful for with realtime export,
and for some cases where a plugin does not correctly reset.
Note that for the first export, plugins are not currently flushed.
add methods to callback.js
automatically reconnect js client on disconnection
mixer-demo do not recreate UI on reconnection
NO-OP: indentation in message.js
make client JS reconnection optional
fix mixer-demo scrolling
minor JS client refactor
improve mixer-demo readability
This allows "stacking" of bindings by desensitizing the actions associated with a "lower" level
of bindings at certain times (e.g. MIDI editing bindings thare are sensitized in the appropriate
editing modes
Cairo::curve_to renders cubic Bézier splines, those are not
generally useful in a DAW context.
Canvas::Curve implements centripetal catmull-rom spline drawing
which can be used for fades and automation interpolation.
This adds a basic support to use multiple sound-cards, currently
limited to two devices: In/Out with shared settings.
Advanced setups still have to resort to using the ARDOUR_ALSA_EXT
environment variable
This apparently happens on some Windows systems when exporting
a range starting at 00:00:00:00
I'm still hoping there's a better fix for these race-condition
issues, perhaps by kicking the TFSM...
When running from the src-tree, ardev_common.sh sets multiple
data-paths, to allow running ./ardev ./gtk2_ardour/ardev.
Pick the first one that contains a "web_surfaces" subfolder as
docroot.
This picks up where cfd95340b1 left off.
The goal is to ensure that the butler has completed all
PostTransportStop related tasks and won't meddle with transport
after exporting has started.
Previously this could happen, because realtime_stop() queues
PostTransportStop and the butler is sommoned after every
export process cycle.
Since 61e7f3176b the butler keeps calling non_realtime_stop()
every time it is woken up, until TFSM comes around and unsets the
flag in the process callback.
This cuts reverb tails and synth sounds after export.
Disabling freewheeling, continues normal processing where
export left off. This previously kept notes ringing, or reverbs
audible.
The actual issue was introduced in 61e7f3176b:
Session::non_realtime_stop() no longer unsets PostTransportStop
(other changes from that commit are not relevant).
The real issue however is a race-condition.
So far this only seems to happen on MacOS, Coreaudio.
It seems that non_realtime_stop() is called in the butler-thread
after exporting has started, even though the butler has been
paused in wait_until_finished().
Perhaps Coreaudio thread switches causes TransportFSM to
reinitialize and scheduling the butler?
The use of `usleep()` makes this rather a workaround.
However it's sufficient for the coreaudio rt thread to run
at least once.
Port (or Tracks) can be safely added during playback, however
the disk-reader's playback buffer is initially empty. This lead to
false-positive Underrun() signals when processing takes place
before or concurrently with re-filling the disk-buffer for the new
channels.
Now new empty buffers are ignored, and produce silence until the
initial refill is complete. There is however no per-channel
de-click in, yet.
This fixes: play some audio track, ctrl+drag a region to the
drop-zone, creating a new track while playing.
Main features: Plugin (Select & Edit)
1. Plugin Select: When a track is selected that has PluginInserts, pushing the "Plug-In" button on a mackie will list these across the strips. Clicking a vpot of a strip enables editing the parameters of this selected plugin.
2. Plugin Edit: When a Plugin is selected for editing, the input parameters of the plugin are shown across the channel strips and the vpot is assigned the corresponsing AutomationControl for the parameter.
Minor features
- When the number of plugins or the number of parameters exceeds the number of strips available on the surface, one can flip through "pages" of views using the Cursor Left and Right keys (this logic I took from http://www.emagic.de/media/support/content/manuals/LogicControl_en.pdf)
- When in the Plugin Select mode, rearranging the plugins in the mixer strip is reflected on the surface.
- When in Plugin Edit mode, rearranging the plugins in the mixer strip still retains the edit view of the selected plugin (rearranging does not take away the current subview)
- When removing a plugin in the mixer strip, this is reflected in Plugin Select, while the view jumps to Pan/Surround (the None subview) when in Plugin Edit mode.
- Removing a track resets the subview to None
- When in a Subview that is track-specific (Track, EQ, Send, Plug-In, Inst), selecting a different track retains the subview but updates the channel displays and vpot assignments accordingly. When in Plugin Edit mode for track A, and track B is selected, it changes to Plugin Select mode for track B (if plugins are present).
Only compare playback latency, delaylines in tracks do not
push back the capture latency to the source.
The delayline on tracks sits in between disk-writer and disk-reader,
delaying input to align with the disk-reader.
Furthermore tracks may be connected to different inputs,
even though those inputs are usually from the same hardware
device, capture latency of those ports can differ.
Ardour5 route templates seem not to have a in the root node playlist
property. Ardour generally relies on that Track::playlist() always returns a
valid playlist. Thus we need to create a playlist even if we don't have a
playlist property in the route template's root node.
This is needed primarily for a workaround for #7971. When importing a template
that has been exported on Ardour5 on MacOS we need to fix the paths of the
archive entries.
Later we can use this functionality also to handle imported templates if
templates with the same name already exist.
This commit only adds methods and members to FileArchive, it does not modify
anything to make regressions unlikely. This, however, leads to some duplicated
code. Eventually we should consolidate this a bit.
Auto-connect is handled in a background thread, so newly created
tracks are not immediately connected.
This causes a race-condition when fan-out directly disconnects
and re-connects ports after track/bus creation.
Track name is implicit, so instead of "meter-<name>", showing a
translatable label "Meter" is sufficient and consistent with "Fader".
Under the hood, for introspection, the processor name remains as is.
This is intended to prevent crashes when unregister_port() modifies the contents of these
two members at the same time that something else is iterating over them.
This exposes custom plugin model/mode. It can be useful for
the GUI to detect if effective settings have changed, and
context-menus have to be re-build.
This reverts commit fac8d84786.
This fixes fan-out. The track should be created before any tracks or
busses are created that are fed by the MIDI track.
The apparent motivation for fac8d847 was MIDNAM related
(there was code in the GUI that needed the instrument, which was
called from within ::add_routes).
This should no longer be the case, the GUI needs to pick up
instrument changes after track creation via processors changed;
besides MIDI busses were still created before the instrument.
* Signals use camelcase.
* use a static signal, independent of the route
Previously the signal was handled by RouteUI, which
caused various issues:
* the RouteUI may not yet be available
* There may be many RouteUIs for a single Route
(mixer, editor-mixer, meter-bridge strips)
This reverts 05c77db773 (revert necessary due to 4637c49838)
Since 4637c49838 we no longer emit Located() in ::backend_sync_callback().
Therefore we must emit Located() in ::locate() even if we are
synced_to_engine().
Otherwise the playhead is not updated when synced_to_engine() in some
circumstances.
When we create a new session and are using a template from an old version of
Ardour, we should not issue the VersionMismatch dialog and not make a copy of
the session file for the old version.
We need to extend the signature of Session::load_state() to tell it if we are
creating a session from a template. Session::_is_new cannot be used for it
because it has a the semantics if to auto connect the the master bus.
* Remove unused direct calls into plugin
* Assume empty model to mean plugin-provided MIDNAM (!)
The route owned Instrument-Info is the central access point used
by the GUI for MIDI name lookups.
At this point in time, custom settings are saved/restored by the
GUI (MidiTimeAxisView). InstrumentInfo provides a volatile store
for MIDNAM mode and model.
If the last read was not looped, but the new one should be, we need to ignore the heuristic. Ditto for vice-versa.
This isomorphic with the read-reversed case
This fixes another assert(), caused by configuring processors,
before set_processor_state() was called.
Route::configure_processors() will be called later.
---
#3 0x00007ffff2472102 in __GI___assert_fail at assert.c:101
#4 0x00007ffff7a8ca1f in ARDOUR::Route::setup_invisible_processors() at ../libs/ardour/route.cc:5013
#5 0x00007ffff7a7a665 in ARDOUR::Route::configure_processors_unlocked at ../libs/ardour/route.cc:1870
#6 0x00007ffff7a79377 in ARDOUR::Route::configure_processors at ../libs/ardour/route.cc:1719
#7 0x00007ffff7a902c0 in ARDOUR::Route::set_disk_io_point at ../libs/ardour/route.cc:6041
#8 0x00007ffff7a7ea0a in ARDOUR::Route::set_state at ../libs/ardour/route.cc:2679
When limiting the message count (e.g. for display in a dialog),
use reverse order, and only print errors.
When loading a session fails, the most recent error is
more likely the real cause.
Previously set_state() -> set_meter_point() acquired the
process-lock to change meter-position, usually causing x-runs
when setting route-state.
This also fixes an issue introduced in fd414ec158. After
populating the processor list, force setting the meter-position
looks up the output streams of the processor before the meter.
However the processors are not configured. That will only happen
later from Session::post_engine_init().
---
#3 0x00007ff07b7d4102 in __GI___assert_fail at assert.c:101
#4 0x00007ff080d3224a in ARDOUR::PluginInsert::output_streams() const at ../libs/ardour/plugin_insert.cc:289
#5 0x00007ff080de8c30 in ARDOUR::Route::set_meter_point_unlocked() at ../libs/ardour/route.cc:4106
#6 0x00007ff080de8699 in ARDOUR::Route::set_meter_point(ARDOUR::MeterPoint, bool) at ../libs/ardour/route.cc:4037
#7 0x00007ff080ddfad3 in ARDOUR::Route::set_state(XMLNode const&, int) at ../libs/ardour/route.cc:269
This fixes the following issue:
On the master channel insert the waveform scope before the fader.
Then set the meter position to custom and move the meter to the
very beginning of the chain.
Before this change, when set_meter_point() was called the
processor list only contained the Fader (_amp) and no other
processor. _main_outs was not yet present in the list, and
Route::maybe_note_meter_position() triggered an
and assert(_processor_after_last_custom_meter.lock());
See also d0dca7daf0
This can help when running with very low latency and the
initial process callback is [indirectly] expensive.
E.g. load a heavy session the a RPi4, initial setup can pull
in a lot of data, which blocks the bus.
In particular with the ALSA backend this can lead to poll timeout
which effectively stops the backend.
This allows for caches to warm up, background worker threads to
spin up and things settle down. This also prevents initial
audible artifacts of live input.
In almost all cases this completes before the GUI is brought up.
When recover() successfully re-initializes the device,
processing can continue just like after an x-run.
This can happen during initial session load of "expensive"
sessions (in particular on slow systems, e.g. Raspberry Pi)
usually with synths. Worker thread pulls in many external
files in the background which blocks the bus for a long time.
resulting in a poll-timeout.
This fixes a deadlock when closing the session.
Session::destroy() takes the engine-lock while removing
unhandled session-events. In [1], the event-queue held a last
reference to a Track, and releasing that object triggered
events (here ~IO) that required the lock.
---
[1]
#2 0x0041743a in Glib::Threads::Mutex::Lock::Lock at /home/ardour/linux-armhf/stack/include/glibmm-2.4/glibmm/threads.h:643
#3 0xb67433ba in ARDOUR::IO::~IO at ../libs/ardour/io.cc:105
#4 0xb6743612 in ARDOUR::IO::~IO at ../libs/ardour/io.cc:111
#5 0xb6758e66 in boost::checked_delete<ARDOUR::IO> at /home/ardour/linux-armhf/stack/include/boost/core/checked_delete.hpp:34
#6 0xb675912c in boost::detail::sp_counted_impl_p<ARDOUR::IO>::dispose at /home/ardour/linux-armhf/stack/include/boost/smart_ptr/detail/sp_counted_impl.hpp:92
#7 0x004178d8 in boost::detail::sp_counted_base::release at /home/ardour/linux-armhf/stack/include/boost/smart_ptr/detail/sp_counted_base_sync.hpp:129
#8 0x00417986 in boost::detail::shared_count::~shared_count at /home/ardour/linux-armhf/stack/include/boost/smart_ptr/detail/shared_count.hpp:426
#9 0xb662343a in boost::shared_ptr<ARDOUR::IO>::~shared_ptr at /home/ardour/linux-armhf/stack/include/boost/smart_ptr/shared_ptr.hpp:341
#10 0xb6a4af7a in ARDOUR::Route::~Route at ../libs/ardour/route.cc:282
#11 0xb6b9404c in ARDOUR::Track::~Track at ../libs/ardour/track.cc:71
#12 0xb697164a in ARDOUR::MidiTrack::~MidiTrack at ../libs/ardour/midi_track.cc:94
#13 0xb697177a in ARDOUR::MidiTrack::~MidiTrack at ../libs/ardour/midi_track.cc:96
#14 0xb6ac525a in boost::checked_delete<ARDOUR::MidiTrack> at /home/ardour/linux-armhf/stack/include/boost/core/checked_delete.hpp:34
#15 0xb6acde00 in boost::detail::sp_counted_impl_p<ARDOUR::MidiTrack>::dispose at /home/ardour/linux-armhf/stack/include/boost/smart_ptr/detail/sp_counted_impl.hpp:92
#16 0x004178d8 in boost::detail::sp_counted_base::release at /home/ardour/linux-armhf/stack/include/boost/smart_ptr/detail/sp_counted_base_sync.hpp:129
#17 0x00417986 in boost::detail::shared_count::~shared_count at /home/ardour/linux-armhf/stack/include/boost/smart_ptr/detail/shared_count.hpp:426
#18 0xb664dca6 in boost::shared_ptr<ARDOUR::Track>::~shared_ptr at /home/ardour/linux-armhf/stack/include/boost/smart_ptr/shared_ptr.hpp:341
#19 0xb6aaf67e in ARDOUR::SessionEvent::~SessionEvent at ../libs/ardour/ardour/session_event.h:42
#20 0xb6a91a88 in ARDOUR::Session::destroy at ../libs/ardour/session.cc:753
#21 0xb6a8fb20 in ARDOUR::Session::~Session at ../libs/ardour/session.cc:460
#22 0xb6a9075e in ARDOUR::Session::~Session at ../libs/ardour/session.cc:46
This fixes a crash with missing [MIDI] write-sources after
duplicating tracks [1]: Stealing write-source name fails, because
there is no write-source.
When duplicating tracks, reset_write_sources() is called before
any playlists are set [2]. So no new write-sources are created
because _playlists[DATA-TYPE] is empty.
During normal track creation write-sources are usually added
by the input-change handler [3]. However in this case the
state has been set, and since there is no change,
DiskWriter::configure_io does not call use_new_write_source()
NB. This also re-creates write-source when playlists are changed.
-=-
[1]
#3 0x00007f4420690102 in __GI___assert_fail at assert.c:101
#4 0x0000562bfa300dc9 in boost::shared_ptr<ARDOUR::SMFSource>::operator->() const at /usr/include/boost/smart_ptr/shared_ptr.hpp:734
#5 0x00007f442579ffa1 in ARDOUR::DiskWriter::steal_write_source_name[abi:cxx11]() at ../libs/ardour/disk_writer.cc:1290
#6 0x00007f4425e476b6 in ARDOUR::Track::steal_write_source_name[abi:cxx11]() at ../libs/ardour/track.cc:476
#7 0x00007f4425d060a2 in ARDOUR::Session::create_midi_source_by_stealing_name at ../libs/ardour/session.cc:4955
#8 0x0000562bf9ed39ab in MidiTimeAxisView::add_region at ../gtk2_ardour/midi_time_axis.cc:1650
#9 0x0000562bf9b05f2a in Drag::add_midi_region at ../gtk2_ardour/editor_drag.cc:568
-=-
[2]
#0 0x00007ffff7582e2f in ARDOUR::DiskWriter::reset_write_sources at ../libs/ardour/disk_writer.cc:946
#1 0x00007ffff757fce6 in ARDOUR::DiskWriter::set_state at ../libs/ardour/disk_writer.cc:333
#2 0x00007ffff7a81c93 in ARDOUR::Route::set_processor_state at ../libs/ardour/route.cc:3054
#3 0x00007ffff7a7f5d5 in ARDOUR::Route::set_state at ../libs/ardour/route.cc:2697
#4 0x00007ffff7c2aa1d in ARDOUR::Track::set_state at ../libs/ardour/track.cc:172
#5 0x00007ffff794f204 in ARDOUR::MidiTrack::set_state at ../libs/ardour/midi_track.cc:152
#6 0x00007ffff7b7e06b in ARDOUR::Session::XMLRouteFactory at ../libs/ardour/session_state.cc:1890
#7 0x00007ffff7addf7e in ARDOUR::Session::new_route_from_template at ../libs/ardour/session.cc:3048
#8 0x000055555621329a in DuplicateRouteDialog::on_response(int) at ../gtk2_ardour/duplicate_routes_dialog.cc:194
-=-
[3]
#0 0x00007ffff7583243 in ARDOUR::DiskWriter::use_new_write_source at ../libs/ardour/disk_writer.cc:996
#1 0x00007ffff75831c7 in ARDOUR::DiskWriter::reset_write_sources at ../libs/ardour/disk_writer.cc:989
#2 0x00007ffff75851ea in ARDOUR::DiskWriter::configure_io at ../libs/ardour/disk_writer.cc:1335
#3 0x00007ffff7a7b308 in ARDOUR::Route::configure_processors_unlocked at ../libs/ardour/route.cc:1912
#4 0x00007ffff7a79e4b in ARDOUR::Route::configure_processors at ../libs/ardour/route.cc:1719
#5 0x00007ffff7a86695 in ARDOUR::Route::input_change_handler at ../libs/ardour/route.cc:3632
Completing readout available() returns 0, until all
background threads have finished and joined.
This also improves performance by feeding suggested/required
amount of samples on every process() call.
