The idea now is that a scroll group item can be added to the canvas which will causes its children to scroll in either or both
directions (horizontal or vertical). There are few complications: the position() of the ScrollGroup is ambiguous depending
on whether you want it with scroll taken into account or not, so Item::canvas_position() was added, which defaults to
the same value as Item::position() but is overridden by ScrollGroup to return the position independent of scrolling. This
method is used when translating between item/canvas/window coordinate systems.
Note that the basic idea is that we MOVE the scroll group when a scroll happens. This mirrors what happens in the GnomeCanvas,
where Nick Mainsbridge came up with a great idea that allowed unification of the time bar and track canvases.
only thin() when writing automation. This fixes issues with
loading short x-fades (which can be stretched later).
TODO: thinning should not just drop, but interpolate and use
more elaborate logic, compared to A2/MB2 Curve::merge_nascent()
fixes http://tracker.ardour.org/view.php?id=5823#c15686
This is only an issue when loading an old session
(pre 3.5.308 - actual change was 21ca6a10) for the first
time with newer ardour.
Saving and re-loading with ardour >= 3.5.308 fixed this as well.
::source_by_path() was written for MIDI files only. I fixed the call and renamed the two similar functions (one for audio and one for MIDI) to make it more clear.
A few things need to be tested / completed:-
1) The code is currently guarded by #ifdef COMPILER_MSVC. This is just precautionary. If it builds okay with MinGW ,the guard can be removed.
2) Windows Playback and Capture devices almost always have different names. This needs to get accommodated in our Backend dialog (as in Mixbus)
3) Windows Playback and Capture devices will almost always contain spaces. We need to accommodate this when writing to .jackdrc (surround them in quote marks)
