The signal exists to notify listeners that something outside of the host's control (e.g. a plugin's own GUI for AU or VST)
has modified a plugin parameter. Previous code had strange feedback loops and ambiguous semantics.
Significant modification of LV2 GUI updating was required.
Still to be tested for feedback loop issues: AudioUnits
- don't attempt to insert two points on toggle.
- remove forced touch->write mode change on toggle
- initial state still wrong, but works much better overall.
- disallow simultaneous events via ControlList::editor_add ()
- clicking on an automation line selects the points that define it.
- don't 'flash' a region selection when using mousedraw mode.
- cp click selection resembles region selection.
- region gain points respect snap modifier (a la automation points).
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.
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)
