There are 3 possible components to draw at each x-axis position: the waveform "line", the zero line and an outline/clip indicator.
We have to decide which of the 3 to draw at each position, pixel by pixel. This makes the rendering less efficient but it is
the only way I can see to do this correctly.
This makes ardour start directly with external jack without asking if jack
was previously used. It also retains jackd settings if jackd was previously
started by ardour.
Also, use Glib::build_filename() rather than hardcoding / as the separator. How did this escape the search for this error?
Conflicts:
libs/ardour/session.cc
roll_delay and latency are only re-calculated when the transport is stopped.
de/activating a track is also not RT-safe.
Conflicts:
gtk2_ardour/mixer_strip.cc
gtk2_ardour/route_time_axis.cc
Remove Canvas::Layout, use Canvas::Container for the same purpose, move child-rendering into Item::render_children() so that it
could theoretically be used by any derived type.
The code relied on the idea that the order-key resync that occurs after deletion would change the order keys and thus cause
a redisplay. But since both the editor and mixer can initiate an order-key resync, the other window's resync will actually
do nothing (the order keys will already be correct). This led to the incorrect placement of material in the tracks canvas,
because the first resync triggered a redisplay while the route still existed, and then the second resync didn't cause a
redisplay (repositioning) but the canvas elements representing the track went away.
Fixed by forcing a redisplay in both editor and mixer if a route deletion is believed to be triggering a row deletion
in their underlying data models.
Conflicts:
gtk2_ardour/editor_routes.cc
The code relied on the idea that the order-key resync that occurs after deletion would change the order keys and thus cause
a redisplay. But since both the editor and mixer can initiate an order-key resync, the other window's resync will actually
do nothing (the order keys will already be correct). This led to the incorrect placement of material in the tracks canvas,
because the first resync triggered a redisplay while the route still existed, and then the second resync didn't cause a
redisplay (repositioning) but the canvas elements representing the track went away.
Fixed by forcing a redisplay in both editor and mixer if a route deletion is believed to be triggering a row deletion
in their underlying data models.
Conflicts:
gtk2_ardour/editor_routes.cc
gtk2_ardour/editor_routes.h
(1) if we're dragging over the drop zone, then x-axis motion is irrelevant for threshold-of-move
(2) store original time axis view of a dragged region so that if we create a new track with the region drag, it can be the same height
