This allows two reader threads to proceed without blocking each other, as can
happen when the butler renders a MIDI track into an RT-safe buffer while the
GUI reads the same MidiModel/Source for visual display.
This also requires a change in the type of reference held by
a MidiAutomationListBinder.
Both the MidiSource and MidiModel have a reference to each other, and it is
important that we avoid circular references to avoid problems with object
destruction. We had been accomplishing this by having the Model hold a
weak_ptr<MidiSource>. However, the lifetime of a MidiSource and its MidiModel
are coincident and there's really no need to use a smart ptr at all. A normal
reference is just fine. However, due to constructors that accept a serialized
state, we cannot use an actual reference (we cannot set the constructor in the
initializer list), so we use a bare ptr instead.
This forces a similar change in MidiAutomationListBinder, which also maintains
a reference to the Source. However, the only purpose of this object is to
ensure that if the Source is destroyed, relevant commands will be removed from
the undo/redo history, and so all that matters here is that the binder connects
to the Destroyed signal of the source, and arranges for its own destruction
when received.
Note that the previous construction of the binder, actually holding a
shared_ptr<MidiSource> would appear have prevented the Destroyed signal from
ever being emitted (from ~Destructible), and so this may also be a bug fix that
allows MidiSources to actually be deleted (the memory object, not the file).
This also requires a change in the type of reference held by
a MidiAutomationListBinder.
Both the MidiSource and MidiModel have a reference to each other, and it is
important that we avoid circular references to avoid problems with object
destruction. We had been accomplishing this by having the Model hold a
weak_ptr<MidiSource>. However, the lifetime of a MidiSource and its MidiModel
are coincident and there's really no need to use a smart ptr at all. A normal
reference is just fine. However, due to constructors that accept a serialized
state, we cannot use an actual reference (we cannot set the constructor in the
initializer list), so we use a bare ptr instead.
This forces a similar change in MidiAutomationListBinder, which also maintains
a reference to the Source. However, the only purpose of this object is to
ensure that if the Source is destroyed, relevant commands will be removed from
the undo/redo history, and so all that matters here is that the binder connects
to the Destroyed signal of the source, and arranges for its own destruction
when received.
Note that the previous construction of the binder, actually holding a
shared_ptr<MidiSource> would appear have prevented the Destroyed signal from
ever being emitted (from ~Destructible), and so this may also be a bug fix that
allows MidiSources to actually be deleted (the memory object, not the file).
In layered mode the scroomer is not usable with stacked MIDI regions.
Ideally we'd only hide it if there is more than one layer
but that is for another day.
Pane::set_divider() constrains the divider so that widget
minimum sizes are honored.
Initially the mixer is empty and the tab has width of ~110px
(just scroll window). Pane::on_size_allocate() calls set_divider()
before actual mixer-strips are added and before the mixer window
size was restored. This incorrectly constrained pane sizes.
This was broken during development of ripple-all.
First explicit rdiff_and_add_command() was used, but
when that was reverted later, the original stateful_diff
was not restored.
989408626d1ccf272d58
* Inhibit prevents any FAs, FA Count, Probability, etc ... but leaves settings intact
* Removed Inhibit from the Right FA menu ... it only needs to be set on the Left
* Removed Inhibit from the clip context menu, we only want shortcuts to explicit actions there
This addresses an issue with missing guard points at the
beginning of a range drag when the range is not snapped to
a musical grid.
Note that the code below "same thing for the end" does not use
.beats() either.
* if the same color is used for the marker and the flag, some range markers looked odd
* now that rulers are highlighted when you hover, it's less necessary to disambiguate by shape
This fixes various offset issues when editing MIDI (CC)
automation as well as RegionGain range and point based editing.
(It does not fix a related issue that region start-trim
offsets region-gain. Historically region-gain _offset is always
zero, regardless of region->start().
Range->Delete is the most common type of ripple-editing imho
... so we need to implement ripple_marks for that common action
* markers inside a deleted range should be removed
* range markers (start+end) need special handling
* remaining markers to the right can be rippled by libardour
* implement undo
