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.
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)
Code to check if we were to close to an edge (for window resizing) blocked all divider setting,
because it would be called with a current widget allocation of 1x1