This is necessary to allow calculation of correct intersection of visible
canvas area and items for the new Item::prepare_for_render() API.
samples_per_pixel must be set first to calculate the new horizontal canvas
position in Editor::set_horizontal_position and then
WaveView::set_samples_per_pixel will eventually call
WaveView::prepare_for_render for those items that are visible on the new canvas
position at the new position.
Or if there is not a change to zoom state then call Canvas::prepare_for_render
explicitly.
Also changes so that each method is only called once during
Editor::visual_changer
Called when an item has requested a redraw and intersects with visible
canvas area.
Also add Canvas::prepare_for_render that will call Item::prepare_for_render for
items visible on the canvas.
First visual change will be processed as normal and then blocked until the
canvas renders the change. If further visual changes need processing then
Editor::pre_render callback will schedule another expose/redraw/render.
This prevents an issue where idle_visual_changer is called many times in
response to events(keys/motion/etc) but the canvas does not get a chance to
render any but the last one which results in a big pause/jump.
This results in a more responsive canvas and in particular a smoother and more
predictable zooming experience.
This multiplier really should be based on the "responsiveness" of the
canvas..or something. I think this is an improvement for more complex sessions
with many regions.
This may need some small tweaks for MB channelstrip to set
print-format (like LV2 plugins would) for cases where the default
value_as_string() differs.
Do not use AutomationType to identify parameters, use complete
Evoral::Parameter and Automatable.
For "batch connections", a Slavables needs to implement an API to return
the relevant controls.
This is only a first step towards a more generic Master/Slave framework.
Let the plugin implementation of Plugin::add_state use a LocaleGuard if it is
necessary (VST/LV2). This puts the LocaleGuards where they are required but the
LocaleGuards in Session::set/get_state will mean these LocaleGuards are a noop.
They are still useful for documentation purposes and in case the code is called
from a non-Session context at some point.
