the actual issues is in the connection management:
bundle.cc:323: void ARDOUR::Bundle::connect(): Assertion `N == other->nchannels().n_total()' failed.
That could be resolved. However, combining tracks without panners will
almost never do what the user really wants, so this case has been
disabled for now.
Glib::operator<<(std::ostream&, Glib::ustring const&) involves
loadlocale which is not thread-safe on OSX.
This fixes various seemingly random crashes on OSX.
Fixes all kinds of miscellaneous issues with MCP. Also removes several theoretical pan modes, replace "Tracks"
pan mode with "Trim", and takes a tiny step towards view modes
Taking a readlock after a writelock in the same thread should result
in a deadlock, yet pthread on Linux returns EDEADLK and continues.
glib-2.42.0 ignores EDEADLK and assumes the lock was taken. Releasing
the lock later causes issues: "Calling g_rw_lock_writer_unlock() on a
lock that is not held by the current thread leads to undefined behaviour."
The issue at hand:
AudioStreamView::redisplay_track()
-> foreach_region() #<< WriteLock
-> add_region_view()
...
-> AudioRegionView::create_one_wave()
-> RegionView::update_coverage_frames
-> Playlist::top_unmuted_region_at() #<< ReadLock
All current users of Playlist::foreach_region() are in the GUI
and AFAICT read-only (display regions, update visuals)
in any way that causes problems, just loss of pre-existing connectivity.
1. retain state of current device (and serialize to disk) when switching
devices, and restore that state when switching back to it.
2. fix port and surfacenaming.
3. fix bundle assembly so that all ports (for multi-surface combos) work.
4. rationalize master position numbering
5. add small sleep before starting device handshake after reconnection. This
is ugly but seems to be necessary, unfortunately.
Increased the size of the FIFO that acts as the intermediate between writers and the MidiBuffer. Changed
implementation of ::write() to notice if MidiBuffer::push_back() fails, and then just leave data queued
for subsequent calls to ::flush_output_fifo().
Note: the logic here will be broken by invalid events/data, which ALSO cause MidiBuffer::push_back() to
return false. That needs fixing
