The ::start_drag() implementation now defers add/extend selection logic to
MidiRegionView::note_selected(), and drops the original limitation that we did
not do extend-selection on button press, only button release.
When adding ffmpeg 5.0 compatibility, the dialog was
dramatically simplified. This re-introduces some options
for audio-quality and also saves/restores settings.
Found via `codespell -q 3 -S *.po,./.git,./share/patchfiles,./libs,./msvc_extra_headers,./share/web_surfaces,*.patch -L ba,buss,busses,discreet,doubleclick,hsi,ontop,ro,scrollin,seh,siz,sord,sur,te,trough,ue`
Previously, when running timefx on multiple regions on
the same track, undo commands accumulated for each region
in the playlist. Resulting in duplicate actions on undo/redo.
```
<UndoTransaction tv-sec="1649607270" tv-usec="646684" name="pitch shift">
<StatefulDiffCommand obj-id="1690" type-name="ARDOUR::AudioPlaylist">
<Changes>
<Regions>
<Add id="4046"/>
<Remove id="2284"/>
</Regions>
</Changes>
</StatefulDiffCommand>
<StatefulDiffCommand obj-id="1690" type-name="ARDOUR::AudioPlaylist">
<Changes>
<Regions>
<Add id="4046"/>
<Add id="4057"/>
<Remove id="2284"/>
<Remove id="2388"/>
</Regions>
</Changes>
</StatefulDiffCommand>
...
```
gtk2_ardour/wscript:15:1 redefinition of unused 'TaskGen' from line 3
wscript:102:9 dictionary key 'sse' repeated with different values
wscript:104:9 dictionary key 'sse' repeated with different values
The code was calling the Gtk::Widget::can_focus() getter as on odd
statement without side effects.
It seems like it meant to call set_can_focus, and thus prepare for
actually grabbing the focus in the next line.
This commit leaves two issues outstanding:
1. unclear/ugly semantics for drag operations that reset the GUI thread's tempo map to the writable copy
2. undo/redo for the tempo map
These will be addressed in future commits
Found via `codespell -q 3 -S *.po,./share/patchfiles,./libs -L ba,buss,busses,doubleclick,hsi,ontop,ro,seh,siz,sord,sur,te,trough,ue`
Follow-up to 364f2f078
Both of these are currently needed: idle_resize() is required for
::set_height() to take effect on all affected tracks, and
::redisplay_track_views() is needed to reposition all other tracks as
necessary.
This may be incorrect, since track height changes may be driven
directly (e.g. via menu items) rather than by mouse drags. This may
need revisiting and there may need to be a way to separate dragged height
changes from others.
This allows it to be used in an idle callback. If we use
::redisplay_track_views() directly, we do not disconnect the idle
connection. This will happen automatically since the callback will return
false, but it seems better to explicit about this. Even better would be to use
::connect_once() but this may not be available in the version of glibmm that we
are using at present.
It appears that GDK/glib will not run idle callbacks with a lower priority than
HIGH_IDLE+10 *if* a new user input event is pending. This means that if mouse
motion events are arriving and causing resizes of selected tracks, the call
to ::redisplay_track_views() which is needed to update all the other tracks,
will not take place if a new motion event arrives. Changing the priority to
same as is used for the ::idle_resize() callback prevents new motion events
from being handled before ::redisplay_track_views() is called.
::model_changed() is used when the model has changed (eg. new notes or some
notes deleted); ::view_changed() is used when only some view parameter (e.g.
zoom, scroll, track height etc) has been altered.
Not fully functional yet (::view_chanted() ignores scroll)
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
* cleaner table layout
* explicit options for bouncing to Trigger and Clip List
* any bounce is added to Source list, so remove that from menu
* format context menus to match "(with processing)"
* use same code structure where possible
Previously every region fragment was added one at a time,
with each emitting signals and updating the GUI. If there are a
few thousand regions Ardour can freeze for a significant amount
of time.
There is still the issue that the GUI freezes after the progress-bar
reached the end: consolidate overlapping ranges after analysis, then
add regions.
And Playlist::flush_notifications still emits
RegionFactory::CheckNewRegion() for every region individually
and RegionListBase::add_region becomes the bottleneck.
But at least adding 7k regions now returns in under 5 minutes
instead of taking over an hour.
This fixes an issue with the videotimeline not being shown
when reloading a session. Editor::set_state() restores the grid,
which in turn changes ruler visibility. This triggers
store_ruler_visibility() and the saved session state was lost.
Changing banks refills the dropdown. This cannot be avoided
since unnamed banks are not in the dropdown, and the dropdown
content can change dynamically. Scroll-wheel does not work reliably.
On macOS, `context->get_targets ()` may be empty when dragging.
In this case the Clip-Picker assumed that a slot is about to
be dropped and switched to the local clip library.
This in turn cleared selection and it was no lnger possible
to drag any clip out of the library.
When auditioning is started, transport controls are disabled
via `set_transport_sensitivity(false)`.
This prevents <space> from being handled:
DEBUG::Bindings: binding for Key 32 (space) state 0 : Transport/ToggleRoll - insensitive, skipped
So the key event is passed on, and can reach the clip-picker treeview
where <space> selects and/or activates a row, which re-starts
audition.
ARDOUR_UI::toggle_roll() cancels audition when audition is active,
so this action should be sensitive, even while auditioning.
For example, the following log text creates a markup error that results in
the session loading dialog being completely empty.
WARNING: VST3<C:\Program Files\Common Files\VST3\Plugins.VST.Someplugin.vst3\Contents\x86-win\Plugins.VST.Someplugin.vst3>: Invalid Module Path
...
Gtk-WARNING **: 16:46:28.447: Failed to set text from markup due to error parsing markup: Error on line 7 char 40: ?Files\Common? is not a valid name: ?\?
The explicit disconnect in the destructor prevents any more signal->connection firing, but the invalidator
is required to remove existing queued slot calls in the receiving thread
Note: this still seems suspicious: we explicitly disconnected from signals in the destructor. However,
it is better form to be able to use invalidator() in the connection call
This just uses the old Evoral BeatTest. Some of the tests needed amending
because temporal uses rint() to convert between float and int, not just
a cast.
Until we have a trimmer, the clip length spinner sets integer beats (beatcnt)
This allows the user some minimal ability to fix a clip of the wrong bpm.
We assumed that 'clips' are already be pre-trimmed to a beat length.
Our internal heuristic always forced tempo to match an integer beatcnt
However: when bouncing a Range to a Trigger Clip, you can know the tempo, and also have a non-integer beat length.
In those cases, the clip-length spinner could behave oddly.
While it's arguably wrong to show integer beats when the internal value is something else,
we still want to show the spinner in integer beats, so it remains usable for its main purpose
This will need some refinement, we should only copy the settings
if the file in question was previously auditioned, and perhaps
only if GMsynth.lv2 is used.
Previously there were two signals for a ::set()
1. Clear Selection -> Emit Signal
2. Select TriggerEntry -> Emit Signal
As result the Trigger Patch Selector was reset and hidden at (1),
only to be set and presented again at (2).
This should perhaps be done for other ::set() calls as well.
This keeps the plugin in sync with any changes made to the
Plugin UI. In particular General MIDI Synth will send
notifications once patch/program changes are processed.
ACE Fluidsynth can load sf2 files, etc.
TriggerEntry has 3 child items:
* play-button, follow-button, name-button.
On mouse-down the TriggerEntry is grab()bed in preparation
to start a drag. From then on all events are directly sent to
TriggerEntry, which can only pass it up to parent items.
Mouse-release hence reaches the TriggerStrip and selects it.
This also changes TriggerBox Selection to act on release
(like all other selection). Otherwise strip selection will
de-select the TriggerBox on mouse-release.
* when a menu uses RadioActions, their initial state must be synced
* we use various methods to 'fix' this throughout the program
-> I'm forcing internal state to match in the case the Action is already active
* question: we tend to use RadioActions for all these menu items,
because they represent a choice between many options;
but do we really need to use RadioActions here?
This properly updates the display if the preference changes.
Even with FILE_CHOOSER_ACTION_SELECT_FOLDER the API is
is get/set_filename -- set_current_folder() sets the parent folder.
