79488873820f66cef28c213401ad98aafaba2f0a
This now follows MIDITrigger - when a region's bounds are changed, we reload the data corresponding to the region into memory, queue up a PendingSwap and then have Trigger::check_edit_swap() switch to the new data when necessary (synchronously with ::run). This comment also removes AudioTrigger::_start_offset because there is never any start offet - the data in memory is always precisely the data corresponding to the region. If the region bounds are modified, we reload the correct data into memory. This also applies to the recently added _user_data_length - again, the data in memory always corresponds to the full span of the region/clip being used in process context. This differs a little from MIDITrigger, where we do in fact load the entire source and maintain trigger-only bounds. That's because the amount of data for MIDI is generally small, and so it makes more sense to just put it all in memory and adjust which parts of it we use. For audio, the region could be minutes (or hours!) into an audio source, and there's no point having all that data in memory when we do not need it. These changes now make editing clip boundaries in AudioClipEditor generally functional, though some polishing is still in the works.
Please see the Ardour web site at https://ardour.org/ for all documentation..
For information on building ardour:
https://ardour.org/development.html
Description
Languages
C++
56.5%
C
39.6%
JavaScript
1.3%
Lua
0.9%
Python
0.6%
Other
0.9%