"AddTrackBus" is a rec_sensitive and write_sensitive action.
However the mixer bypasses this and unconditionally calls
ARDOUR_UI::instance()->add_route () in various cases
(right-click on blank space or scroller, left-click on "Add" buttons
in the VCA pane, route pane, etc).
Since those are direct events, not related actions, they need
to be explicitly ignored.
Ideally the "+" buttons would be made insensitive...
The stereo-width panner is not generally useful. In order to
change the azimuth, width has to be reduced, which usually leads
to comb-filter artifacts.
Equal power stereo, also matches the default mono to stereo panner
better than the stereo-width panner.
Last but not least, control surfaces only have an azimuth control
knob, without an easy way to reduce width, this leaves
the panner insensitive.
Direct call to Session::cleanup_sources() from ARDOUR_UI::cleanup()
didn't zero initialize size. This centralizes initialization,
so cleanup_trash_sources() does not need to explicitly clear it.
Previously when loading Ardour v2, v3-5 sessions, tracks were
created with a dummy name "toBeResetFroXML".
In v6, Track::init() creates a playlist when the track name is
not empty. Later Track::set_state() calls set_name(). When a
playlist exists, the playlist's name is set to match the track's name.
When loading v6 sessions none of this happens. A previously loaded
playlist will be assigned by ID.
Older versions identified Playlists by name and by the time the
playlist is assigned, there may be ambiguities. With the default
(track-name = playlist-name) two playlists with the same name exist:
(1) the playlist loaded from the session file
(2) the playlist created by Track::init()
Playlists are stored in an ordered std::set<shared_ptr<Playlist>>,
and name-lookup iterates over the set.
When loading an old session after starting Ardour, it is very
likely to always lookup the playlist (1), because new, later
allocations from (2) are on top of the heap and ordered last.
The session seemingly loads correctly, except for lingering,
unused empty playlists "toBeResetFroXML" renamed to "Track name"
that were never deleted.
However when loading an old session from a running instance,
ordering is mostly random, and many tracks end up with using
the empty playlist (2) instead of the correct playlist (1).
in 5.x, we would only run the MTC parsing code if slaved to MTC. That's no longer true in 6.0, and without
this change, MTC will cause a locate at startup
When switching the Mixer to show sends, using _amp as
intermediate for automation is not correct.
The control is not owned by the amp.
The same is true for VCAs, prefer the control (see 8400ebd175)
This fixes issues with send-panner bypass whenever the
target bus input-count is different from the send's channel count.
--
Previously, when the aux-send panner was bypassed, data was
copied using BufferSet::read_from().
This sets the channel count of the output buffer set (here: mixbufs)
to match the input (here: bufs).
e.g. mono to stereo, "1 in -> 2 out" out was changed to "1 in -> 1 out".
Un-bypassing the panner later does not reconfigure the I/O.
Mixbufs remained mono, and PannerShell::run() "1 in -> 1 out"
does nothing. The panner was effectively not functional.
gcc-8.2 -O3 optimization enables -finline-functions.
For reasons yet unknown this causes issues with Glib::Threads::Private
when loading sessions (creating new ones is fine) and likely some
other operations.
Without this change the following happens (5.12 as well as current git)
when loading an existing session:
---
[Switching to Thread 6092.0x12fc]
Breakpoint 1, ARDOUR::SessionEvent::create_per_thread_pool (name=..., nitems=4096)
at ../libs/ardour/session_events.cc:60
60 in ../libs/ardour/session_events.cc
$6 = (const std::__cxx11::string &) @0x210dfc60: {static npos = 18446744073709551615,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
_M_p = 0x210dfc70 "GUI"}, _M_string_length = 3, {_M_local_buf = "GUI\000\000\000\000\000<E0>P<DA>:\000\000\000",
_M_allocated_capacity = 4805959}}
#0 ARDOUR::SessionEvent::create_per_thread_pool (name=..., nitems=4096) at ../libs/ardour/session_events.cc:60
#1 0x0000000000434e77 in ?? ()
[..]
Thread 1 (Thread 6092.0x12fc):
#0 0x0000000061f152ef in PBD::RingBuffer<void*>::write (this=this@entry=0x50, src=src@entry=0x210dcdc8,
cnt=cnt@entry=1) at ../libs/pbd/pbd/ringbuffer.h:170
#1 0x0000000061ee954d in push (t=<optimized out>, this=0x0) at ../libs/pbd/pool.cc:290
#2 CrossThreadPool::flush_pending_with_ev (this=0x0, ptr=<optimized out>) at ../libs/pbd/pool.cc:254
#3 0x00000000218d5b01 in operator() (a0=0x210dcdc8, this=0x48)
at /home/ardour/win-stack-w64/include/boost/function/function_template.hpp:682
#4 operator()<boost::function<void(ARDOUR::SessionEvent*)>, boost::_bi::list0> (a=<synthetic pointer>, f=...,
this=0x68) at /home/ardour/win-stack-w64/include/boost/bind/bind.hpp:259
#5 operator() (this=0x48) at /home/ardour/win-stack-w64/include/boost/bind/bind.hpp:1294
#6 boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (ARDOUR::SessionEvent*)>, boost::_bi::list1<boost::_bi::value<ARDOUR::SessionEvent*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...)
at /home/ardour/win-stack-w64/include/boost/function/function_template.hpp:159
#7 0x0000000063e2dc39 in operator() (this=0x210dcf70)
at /home/ardour/win-stack-w64/include/boost/function/function_template.hpp:682
#8 AbstractUI<Gtkmm2ext::UIRequest>::call_slot(PBD::EventLoop::InvalidationRecord*, boost::function<void ()> const&)
(this=0x3ada50e0, invalidation=0x0, f=...) at ../libs/pbd/pbd/abstract_ui.cc:434
#9 0x00000000216cbb96 in ARDOUR::SessionEventManager::merge_event (this=<optimized out>, ev=<optimized out>)
at /home/ardour/win-stack-w64/include/boost/function/function_template.hpp:507
#10 0x00000000216e3861 in non-virtual thunk to ARDOUR::Session::queue_event(ARDOUR::SessionEvent*) ()
at ../../win-stack-w64/include/glibmm-2.4/glibmm/threads.h:709
#11 0x00000000216c91bf in ARDOUR::SessionEventManager::clear_events(ARDOUR::SessionEvent::Type, boost::function<void ()>) (this=this@entry=0x4256cc08, type=type@entry=ARDOUR::SessionEvent::Skip, after=...)
at ../libs/ardour/session_events.cc:156
#12 0x000000002168874a in ARDOUR::Session::sync_locations_to_skips (this=this@entry=0x4256ca90)
at /usr/lib/gcc/x86_64-w64-mingw32/8.3-posix/include/c++/new:169
#13 0x0000000021688802 in ARDOUR::Session::update_skips (this=this@entry=0x4256ca90, loc=loc@entry=0x0,
consolidate=consolidate@entry=false) at ../libs/ardour/session.cc:1683
#14 0x0000000021699649 in _locations_changed (locations=..., this=0x4256ca90) at ../libs/ardour/session.cc:1859
#15 apply<ARDOUR::Session> (method=
(void (ARDOUR::Session::*)(ARDOUR::Session * const, const ARDOUR::Locations::LocationList &)) 0x216994f0 <ARDOUR::Session::_locations_changed(std::__cxx11::list<ARDOUR::Location*, std::allocator<ARDOUR::Location*> > const&)>,
obj=..., this=0x40ff4c60) at ../libs/ardour/ardour/location.h:240
#16 ARDOUR::Session::locations_changed (this=this@entry=0x4256ca90) at ../libs/ardour/session.cc:1840
#17 0x0000000021700abd in ARDOUR::Session::set_state (this=0x4256ca90, node=..., version=6000)
at ../libs/ardour/session_state.cc:1657
#18 0x0000000021713456 in ARDOUR::Session::post_engine_init (this=this@entry=0x4256ca90) at ../libs/pbd/pbd/xml++.h:81
#19 0x00000000216ad5cd in ARDOUR::Session::Session (this=0x4256ca90, eng=..., fullpath=..., snapshot_name=...,
bus_profile=<optimized out>, mix_template=...) at ../libs/ardour/session.cc:383
#20 0x000000000046db8b in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
---
Note that in the trace starting at #19 the source-file references
are offset :post_engine_init() isn't in xml++.h
(likely debug symbols are incorrect due to inline functions)
The application crashes due to #2 ::flush_pending_with_ev (this=0x0 ..)
But the earlier breakpoint above shows that the ThreadPool was
created, and this #11 ::clear_events() should not assign NULL.
(This happens on a single-core CPU, too)
Locating the start of the loop range at transport start does not count as "have looped". This was preventing
pre-roll when starting to loop, which in turn caused data/event loss because the start/end sample ranges
would be incorrect inside process
