* Draw antialised waveform if waveform is monotonic
* Fix center-line position (span at most height - 1),
* Remove invalid "side-lines" that were previously
drawn around spikes.
* Do not linearly center min/max when drawing log-scale
* Fix offset of lower outline and clip indicators
This was changed in fc9840f2a9 to hard code a "false" argument describing
whether or not the child bbox had changed. This causes the parent to not
recompute its own bounding box when a child is shown/hidden, which is
incorrect. We now force it to true, which may be overkill for some purposes,
but at worst will just force an unnecessary bbox re-computation and nothing
more.
When loading a session, we now just set up port state, which will
populate the Port::_connections member, and then once all ports have
been created, use PortManager::reconnect_ports() to get everything connected.
If connecting ports using the port-engine fails,
ardour forgets the connection.
Internal backends only produced an error if a port was already
connected, when using ::connect (handle, other), but
ignore already existing connection when using port-names.
Various ports are connected twice when the engine connects
at session load. This worked fine for as long as the engine
was never stopped (saving the session asks the port-engine),
but failed when the engine went away and internal representation
is used.
During initial setup, PortManager::reestablish_ports(),
the jack client is not yet active and port_connect failed:
"Cannot connect ports owned by inactive clients".
Later hotplugged devices were likewise not connected because
"JACK: Cannot callback the server in notification thread!"
see also 2007bf2d5f
A physical input port must remain connected to ardour's
physical_midi_input_monitor_enable port, otherwise reading
its input can cause crashes.
Previously a MIDI input port was disconnected from all other
targets when "MIDI input follows selection" was enabled.
a negative beat position needs to be legal, so the assert was moved and modified. The only check
for a negative value is that the TempoPoint being used is at absolute zero.
This check might turn out to be wrong in the future, but for now we still require a tempo and
meter point at absolute zero
