A complete reimplementation of AudioGrapher::SilentTrimmer::process to support
trimming the beginning and end in the same processing block
Fix export with trim end enabled to actually trim silent frames
Only add silence to beginning or end of export data if data was written
Should resolve: #6412
Unlike many of the other uses of the term "frame" this is actually returning
the index to the first sample in the interleaved frame that contains
non-silence.
With end trim enabled, the only case that would successfully export was if
there was at least some samples above the silence threshold in the last export
processing block.
The issue was that the EndOfInput flag was not being passed to
AudioGrapher::SndFileWriter::process which would then call sf_write_sync and
emit the FileWritten signal to start post processing. Fix that by always
passing the EndOfInput flag in the last export process cycle.
Related: #6412
All float values defined in the CONFIG_VARIABLE macro seem like they are cast
to at some stage before writing (another issue that needs addressing). The
default value for export-silence-threshold (-INFINITY) is converted to a value
of 0 and as a result nothing is exported with trim enabled.
Use the same fixed silence threshold as Mixbus until proper bounds checking and
GUI is in place.
Related: #6412
Just an update to slightly rotten wscripts, shouldn't be any changes during an
ardour build. Motivation being a short development cycle for working on evoral
and/or its test suite.
Note the old Note::operator= was unsafe, since it made shallow copies of the on
and off events, which results in a double delete of events when the notes are
destructed.
I'm not sure if this is really the best way to do event types (should it
just be a completely static enum in evoral, or completely dynamic and
provided by the type map, or a mix like currently?), but previously the
event type was frequently set to either total garbage, or parameter
types, which are a different thing.
This fixes all those cases, and makes Evoral::EventType an enum so the
compiler will warn about implicit conversions from int.
It is slightly questionable whether type specific methods like
velocity() belong on Event at all, these may be better off as free
functions. However the code currently uses them as methods in many
places, and it seems like a step in the right direction, since, for
example, we might some day have events that have a velocity but aren't
stored as MIDI messages (e.g. if Ardour uses an internal musical model
that is more expressive).
In any case, the former inheritance and plethora of sloppy casts is
definitely not the right thing.
