This involved a significant change in event handling for automation region views,
but it brings it into line with how it works for other things. On button press
we initiate a drag, then if no motion occurs, the Drag returns false during
finalization, and only then do we continue through Editor::button_release_handler()
to eventually end up in ::add_automation_event().
Although it is a substantial change, the fact that it now works the same
way for audio regions, automation regions and automation tracks seems
like a definite plus.
This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
There already is a shaded coverage frame indicating
if a layer is audible. This leads to a more consistent view.
In addition changing layered mode now has to update the
colors (set_frame_color).
A fully transparent waveform (with only a semi-transparent outline)
looks very odd with all themes.
Perhaps this was a typo and the initially intended rendering was
supposed to be 31% transparent, however this is not distinguishable
from non-opaque regions (27% transparency).
RegionView::make_name already adds the prefix, AudioRegionView
does not need to add it again.
Also the font used on macOS (Lucia Grande) has a rather limited
UTF-8 charset and does not support:
\u20F0 (COMBINING ENCLOSING CIRCLE BACKSLASH)
\U0001F507 (SPEAKER WITH CANCELLATION STROKE)
so for now we keep using "!" on macOS.
AudioRegionView() c'tor calls create_waves() early on
before the _height is set [1].
Now one following can happen:
1. All peak-files are present. create_waves() directly calls
create_one_wave() for each channel. They are initialized
with zero height.
But all channels are present so waves[] is populated and
a later call to set_height() corrects this
2. All peak-files are still missing. create_waves() schedules
callbacks via PeaksReady -> peaks_ready_handler()
Those callbacks arrive after set_height() was called and
the waveforms are displayed correctly.
3. Only some peak-files are present. This can happen at
rec-stop when the region is created.
create_waves() directly calls create_one_wave() for available
peaks, and schedules peaks_ready_handler() for the remainder.
The directly created waves have zero-height.
Since not all waves are ready, they are stored in tmp_waves.
waves[] remains unpopulated.
The set_height() call only ever changed the height of wave[], which
resulted in hidden waveforms, until a user manually changed the
height of the track.
[1] the height is set from
```
#1 AudioStreamView::create_region_view(boost::shared_ptr<ARDOUR::Region>, bool, bool)
#2 AudioStreamView::add_region_view_internal(boost::shared_ptr<ARDOUR::Region>, bool, bool)
#3 StreamView::add_region_view(boost::weak_ptr<ARDOUR::Region>)
...
## PBD::Signal1 Playlist::RegionAdded()
```
Since rebuilding peaks does not call drop-references, the WaveView
is not explicitly released. and ArdourWaveView::WaveView
keeps a shared pointer reference to the AudioRegion.
This also fixes a memory leak, waves, tmp_waves store C++ pointers,
not shared pointers. Explicit delete is required
* Shade muted regions only when they are not selected, nor
being dragged.
* Selecting and Dragging a region adds alpha, so that
underlying regions and the grid become visible.
* record-red trumps.
Copyright-holder and year information is extracted from git log.
git history begins in 2005. So (C) from 1998..2005 is lost. Also some
(C) assignment of commits where the committer didn't use --author.
This is a backport from Mixbus, to leave are 4 "open" pixels
at the bottom of the track so one can see the grid-lines between tracks.
This is useful with low region-transparency. grid-lines behind
opaque regions are not visible.
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
snap now fills in a struct (MusicFrame) which contins a snapped frame
along with a music divisor.
this gives useful information wrt magnetic snap which may or may not
have rounded to an exact musical position.
region position may now be set musically (using quarter notes for now).
this patch fixes several problems in the current code:
- dragging a list of music-locked regions now maintains correct
musical offsets within the list.
- splitting regions using magnetic snap works correctly (#7192)
- cut drag should now work correctly with magnetic snap.
- musical length of split midi regions is no longer frame based.
