'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()
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.
The iterator into the model can become incorrect in the sense that it is no longer the correct
next event to play. This can happen at least with a tempo map change, and possible under other
conditions. Catch this when it happens, and act as if we reached the end of the trigger
This change still runs the triggerbox during latency-preroll, but as with the disk reader,
the transport speed argument is set to zero. The triggerbox notices this and behaves
appropriately (I think !)
Rather than start at zero, we now search backwards for the first relevant cue
before the locate position, making our task in ffwd'ing from there much simpler
since there are no other cues to consider
* there are rare cases where a midi clip would not advance the ffwd position, looping endlessly
* this problem did not occur when the user chose an explicit Follow Length (different code path)
This workaround bypasses RegionMap and SessionPlaylist APIs
(region_use_count, destroy_region) which are not directly
applicable to Triggerboxes. There are likely various edge
cases until TriggerBoxes integrate with Session Playlist.
e.g. whole file regions generated for regions/source used by
triggerboxes are cleaned up.
There was a logic error previously which failed to consider follow actions (and follow count).
Now we find a relevant cue, and use follow actions and follow counts as we move forward
in time
Note that ::find_all_sources_across_snapshots() finds and retains
all sources in the SourceList of other snapshots regardless
if they are used in those snapshots.
if a slot becomes active, and the transport is not rolling, it still
asks the transport to roll. however, (1) there's only 1 request across
all triggerboxen (2) the request will not be handled till the next
process cycle (3) the triggerbox returns after the request i.e. it
waits until the transport is rolling
Previously it was possible to cause a 64bit signed to 32bit
unsigned overflow. `from_stretcher` is pframes_t aka. uint32_t.
With int64_t arguments a std::min() expression producing negative
result will result in large 32bit values:
(pframes_t) std::min<int64_t>(1024, 176400 - 187392) = 4294956304
This produced a segfault when used as n_samples to copy in
buf.accumulate_from()
Session handles the case when the button is used to enable cue triggering, by
forcing a locate to the current transport position.
TriggerBox now connects to the correct configuration object to notice when cue
triggering is disabled, and sets _cancel_locate_armed appropriately.
this solves the oft-recurring problem where we assign
a beat-count of '3' or '7' because minipm mis-detected the tempo,
and that situation is vanishingly rare. it's better to assume 4 or 8
the user always has the option to change the number of beats (and
therefore the detected tempo) manually, for those clips that are
in a different time signature. but minibpm cannot be expected
to help us there.
NOTE: this is a fallback to make things 'just work' lacking any other context.
* if the tempo is detected in the filename, we use that instead
* clips that were recorded to the timeline use that bpm+timesig
* in the future we can use file-metadata (acidized wave?) instead
* this is audio-only: midi files can have an embedded timesignature
but... given no other information, experience says the vast majority
of downloaded/purchased clips will be 1,2 or 4 bars at 4/4.
bugfix: changing the FA state can overwrite the clip's name and color
Some params (like gain) can and should take effect immediately
by directly setting the properties. TRIGGER_DIRECT_SET does that.
But we still, ALSO have to set the ui_state, because when the
triggerbox imports ui_state via update_properties() it will
overwrite your changes.
Said another way: since we use a queued ui_state to set the properties,
you ALWAYS have to set and use the ui_state mechanism, even if you want
to short-circuit the process for specific properties.
Ben Loftis
Paul Davis
Robin Gareus
luz paz