'unbang' is better described as a mouse-up or button-release event
* if launch-style is Gate or Repeat, then UnBang will stop the playing clip
* in other launch-styles, UnBang is ignored
some prior code using UnBang will change to
stop_quantized() or request_stop()
Grid controllers will largely want to access clips in the order they appear on the Cue page
It is up to the device (and/or its ControlProtocol) to handle banking
normally we operate on TriggerPtr's which are a safe way to track
trigger lifetime, safely modify their properties, and launch them.
bang_trigger_at() is a convenience function to look up a trigger by index,
and launch it, in one step. Potentially useful for control surfaces.
We now try to get to the right location within the MIDI data and continue
playing, rather than pretending that we reached the end.
This also fixes a thinko that caused only the first few notes of a
MIDI trigger to play.
This may also solve cases where due to length, sample rate and tempo
settings, a trigger finished precisely on a ::run() call boundary.
* allow to update IR data
* allow to use mono processing in base-class
This is handy for FIR (Readable/ROM), and operating directly
on local data (ratherer than mapped buffers)
For some reason applying the property change
plist.add (Properties::start, std::numeric_limits<timepos_t>::min());
does not correctly reset the offset of the newly created region.
The during trim-front, the call order is
1. Region::set_position_internal
2. Region::set_length_internal
::set_position_internal sets `_last_length.set_position (position());`
but the later call ::set_length_internal does `_last_length = _length;`
This sets last_position() == position(), and later Region::mid_thaw()
does not call Region::recompute_at_start().
Region gain envelope was not updated.
see also 00a1b7cb24 and 13d10582f0
Previously, the copied source file only contained data within the initial region bounds. This
meant that you could not trim the (unlinked) copy to beyond its initial bounds. Seems wrong.
VST preset restore has to happen in the GUI thread, specifically
the plugin's own UI event-loop (which on Linux and Windows is
not usually Ardour's Thread 1). However if there is no plugin
GUI, it should be safe to use Ardour's UI thread.
RegionFactory::create(Region&,..) copies all region properties.
There are however various operations that use a new Source
as intermediate to create a new Region from another Region.
Those operations should also inherit various region properties
(such as mute, opaque, locked, ..)
This effectively triggers a Session::request_overwrite_buffer
via Playlist::notify_contents_changed when the time-domain of a
Region changes.
When the time domain of a MIDI region changes, Region boundaries
and events positions change ever so slightly. The playlist has
to be rendered again to take this into account.
When MIDI regions with different time-domains are layered, notes
may not be resolved in correct order. Previously changing time-domains
to address this did not result in the playlist being reread.
This adds a special case of "flush/resolve" to restore the
state of an upper layer opaque MIDI region while at the same time
resolving notes of a lower layer region.
