Session::process() returns early with Session::_silent set to true. AudioBuffer::set_data()
was never set for (at least) the LTC output port. PortManager::cycle_end() calls
AudioBuffer::silence() which used to assume that get_buffer() must have been called. But it
was not, because that should have happened in Session::process().
So check AudioBuffer::data() and call get_buffer() if required.
The trim processor was moved to the front after the internal return was,
so the trim setting was applied before the signal coming from other
tracks/busses sends was mixed in. Change the order so that trim applies
to audio from internal sends as well.
To export a MIDI region to a file, the code used MidiRegion::clone()
since it takes care of creating a new file-backed source with the wanted
contents. Nevertheless, it had several side-effects:
- it created and registered a new region which is confusing to users
- it only exported notes that were in the region range, but didn't
remove the region start offset from MIDI events, essentially producing
a spurious silence at the beginning of the exported file (this is not
a problem for region cloning because the newly created region is made
aware of the offset and caters for it).
Add a dedicated code path for export, that uses the new offsetting
capabilities of MidiModel::write_section_to().
MidiModel::write_section_to() only wrote events to the given source if
those events had a time in the given range. Make it able to optionally
offset event times so that the start of the written range corresponds to
time 0 in the source.
Instead of mixing two consecutive biquad orders with a linear xfade, the
code used the same weight for both signals to mix, due to a copy-paste
blunder. Brown-bag fix this now. Also change a little the threshold for
using 32-samples chunks to cater for steepness jumping from 0 to 4 (this
doesn't change anything for commonly used rates and is just for
robustness in never-happening cases anyway).
PortMatrix is able to filter out ports that have an unwanted datatype, but
if a Bundle is added that has no port at all with a wanted datatype then
it is not weeded out correctly (and even if it were, there's no chance
that it will legitimately appear in the UI). Don't add that kind of
Bundle in the first place.
Since lua functions are closures, C++ methods that pass arguments by
reference cannot be used directly. The previous approach (boost::ref)
failed with clang. Assume the following:
void foo (float&) { }
static inline float& bar () {
boost::reference_wrapper<float> r (42);
return r.get ();
}
foo ( bar () );
With gcc, "r" goes out of scope after foo's arguments are processed
and all is well.
But with clang, "r" already leave scope when *inlined* bar() returns.
Solution: allocate some user-data on the lua-stack to hold the reference.
There is no reference to this user-data so lua will eventually
garbage collect it.
(theoretically, creating the table which holds the return-values
could trigger an emergency garbage collection when memory is low and
free the reference just while they're being pushed to the table, then
gain FuncArgs<Params> already dereferenced them all as variable on the
C stack -- probably again compiler specific)
