gcc can recognize various regexps in comments. Since C++17 provides
[[fallthrough]], using /* fallthrough */ consistently seems
appropriate until we switch to C++17.
see also https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
A "fall through" comment is most portable way to indicate
"no break, fallthru" cases.
* __attribute__ ((fallthrough)) // is not portable
* [[fallthrough]]; // is C++17
This also removes enums introduced to describe well-known parameters for Mixbus. Lookup now involves string
parsing every time, but this is not likely to be a notable cost.
smf_delete() does not handle NULL, and segfaults instead.
This only crashes with optimized builds.
libsmf will call g_critical() earlier and in that case debug-builds
call UI::handle_fatal() and ask the user to "click to exit".
This is mostly to see if there'll be any problems when merging these changes into Mixbus. I'm guessing there'll be some conflicts in these projects (and a lot more to follow...)
* lock list when editing (prevent concurrent modification of insert
iterator
* don't add a guard-point if an event is already present between the
target and guard-point-position
* remove existing automation-events (old guard points) when
touching automation w/o change
* don't unset "new write pass" when not rolling
(fixes issues when not rolling but locating with write-enabled)
AudioRegion::set_fade_in() freezes the original ControlList, then
assigns a new one and thaws that.
Frozen state needs to be retained during assignment.
Related: The overloaded assignment operator in AutomationList
performed duplicate signal emission and didn't freeze the list.
Ardour may have ignored log-scale for parameters 0..N and allowed
writing '0'. Force those values into the valid range on session load.
Also mark the list as "needs sorting" which removes potential duplicates.
The Control and ControlList uses the raw value (eg. coefficient for gain,
Hz for frequencies) and those Lists are stored in existing sessions.
In the vast majority of cases interpolating automation values using exp/log
scale for dB, freq makes more sense -- it's also what the fader does.
Adding additional interpolation methods is future proof (we might at allow
to even add different methods per automation point (to the next) like other
DAWs do.
Currently it's mainly used in preparation for consistent GUI automation-
lanes. Between 2 points there's always a visual straight line.
This allows complete mathematical description of a given parameter
and parameter values.
Semantic type abstraction is reserved for Ardour::ParameterDescriptor.
