This is tricky to explain, so rather than explain what was wrong, I'll describe
how it works now.
Whenever a ScopedTempoMapOwner::in() call occurs, we check the current thread-local
tempo map ptr. If it is not owned by us (and we have a local tempo map that we
want to use), set it so that it is.
We continue to fetch() the global tempo map ptr back into the thread-local ptr
when the local scope depth drops to zero.
Correctly divide the fractions of *available* requested child-space.
This fixes issue with Trigger Page bottom attachment not showing
Frame content.
When calculating constraints the divider width/height was ignored.
When setting child allocation, the divider girth was only
subtracted *after* the first child, and iteratively subtracted
after each subsequent child widget.
This over-allocated the first child and later child widgets
were increasingly too small (factor * remaining).
If the user attempted to access a view with no tracks in it, it would
show all blank screens. Now, it will show a temporary warning message and return
to the previous view.
When a user changes a value in the Plugin GUI, JUCE informs the
DSP behind the host's back, and later informs the host from the
DSP (realtime) thread, by sending patch:Set messages from the DSP
back to the host/UI.
This is really bad practice, particularly since the plugin does
no even use LV2 instance access, or LV2 data access features.
Processor changes trigger configure_io() which resulted in a
call to reset_write_sources(), which is a disaster while recording.
This allows adding plugins while recording, and prevents adding
any plugins before the disk-writer that change the channel-count
while recording, or changing strict-i/o to the same effect.
This code only worked for port groups that themselves (the specific group
instance) listed their designations. This worked with LSP, which redundantly
duplicates the elements from the group's class for some reason, but not with
other plugins like MDA which simply refer to a standard group like
<http://lv2plug.in/ns/ext/port-groups#StereoGroup>.
This does require the specification data to be loaded from the LV2 path (maybe
why LSP does that?), but that's generally expected for anything LV2 to work.