Program Changes are stored as an offset from the 'source' start, and must be translated to/from region time.
Better locating of patches wrt the grid:
You can't assume time_to_pixel is steady across the timeline
* calculate position of the patch-change flag
* calculate region start position, and set flag's x offset from there
also: consolidate patch-location code into display_patch_changes()
When adding a note, use these criteria to choose the channel number:
* if the user has explicitly specified a note in the pulldown, use that
* if the user has AUTO selected and we are in a region, choose the nearest note's channel (consistent with velocity behavior)
* as a fallback, query the track for its channel-filter (old behavior)
The objects referenced by markers point to the copy of the map held by the per-thread ptr. But
the edits must be done on a writable copy of the map. ::reassociate_metric_markers() fixes
the references to use the writable copy, so that when we pass references to the objects in the map
to the writable copy, it will find them and modify them (rather then ones in the previous
generation of the tempo map)
TempoMap::use() merely returns the current per-thread tempo map
pointer; if a change is signalled, we should force an update
of the per-thread ptr via TempoMap::fetch()
This is all done in the GUI, using GUI objects. THe primary goal
here is to allow actions to be applied to selected triggers, so
there's no real need for a trigger aspect to libardour (core)
selection.
Important logic from 6.9 was either missing or incorrectly implemented. New
version is much simpler - we just use the RoundDownMaybe mode of round_to_bbt()
to ensure that the note start is always within the current grid even if the
mouse is more than halfway "through" it.
