RouteUI::set_route() already does the right thing. Also remove RouteUI::mute_changed() since its
only role was to handle the mute change signal from a route, which boost::bind() makes unnecessary
since we can connect update_mute_display() directly.
This moves MIDI channel filtering into a reusable class and moves filtering to
the source, rather than modifying the buffer afterwards. This is necessary so
that the playlist trackers reflect the emitted notes (and thus are able to stop
them in situations like mute).
As a perk, this is also faster because events are just dropped on read, rather
than pushed into a buffer then later removed (which is very slow).
Really hammering on mute or solo still seems to produce stuck notes
occasionally (perhaps related to multiple-on warnings). I am not yet sure why,
but occasional beats always.
During DnD, the region uses the 'old/current'
midi_stream_view()'s range and its position/height calculation.
Ideally DnD would decouple the midi_stream_view() for the
region(s) being dragged and set it to the target's range
(or in case of the drop-zone, FullRange).
but I don't see how this can be done without major rework.
For now, just prevent visual bleeding of events in case
the target-track is smaller.
* Handle large (delta > 1) movements into the DZ
which are not due to invalid-drop positions, but
caused by laggy GUI or rapid user movements.
* ignore busses when moving out of the DZ.
Allow to drag multiple regions from different tracks
to/from the dropzone.
Busses & Automation-lanes are ignored, as are
hidden tracks.
Any region may serve as mouse drag anchor.
fixes#6172 and #6176
Fixes bug #6214.
It would be better to do this while dragging, but this would require rewriting
much of the drag code to keep track of a cumulative y delta since the current
position of points would be "sticky" and prevent any movement at all, so this
will have to do for now.
Fixes#6172 and #6176 for single region drags.
Further work is needed if multiple regions on different tracks are dragged over hidden tracks
(see inline comment).
“number of visible tracks”: count automation lanes
as tracks. Distribute equally.
“Summary View”: the visual lane represents both
track + automation. Set the total height.
Left to do: recursive “Shrink” and “Expand” tools
if there is no explicit selection.
preparation for further Summary and Number of visible
track count fixes.
* “Only Self”: don’t resize child-views (old default)
* “Total Height”: distribute height equally among
all visible child [automation] lanes
* “Height per Lane”: given height should be applied
to all sub-views.
If a custom LED color is used, the LED does not
reflect the ExplicitActive state. Hence the
Body Element (if visible) should be used just like
for buttons without LED indicator.
not only does this provide consistent look & feel,
but now the status-bar can never be empty.
Before to this change, a small useless black
rectangle remained when all elements were hidden.
Thanks to brilliant detective work by John E. we
can now reveal that the actual crash in
EngineControl::print_channel_count() is caused
by a seemingly unrelated exception.
The root cause however is waves/ASIO backend reporting a
buffersize that is not in list of available buffer-sizes
it reported earlier.
In theory, the EditorSummary::get_editor()/set_editor() calls
should be no-ops if the values are just passed between them,
but this turns out to be not precisely the case. Rather than
figure out exactly how ensure that this is true, mark the
new rect boundaries for the non-moving axis with -1 so that
we know to leave it alone
Add an option to insert new routes at the top of the list ("First").
Reorder/rename the entries in the dialog.
Session's _order_hint is now the signed int it always wanted to be.
The previous code assumed that dragging up from the drop zone into the last
track is always valid. This is not true when the type of the dragged region(s)
do not match that route, which resulted in a crash and/or bizarre behaviour.
This took entirely too long to figure out, there are some real nightmares in
the region drag code...
This has been tested, but needs testing on more platforms (check for
obscured windows/dialogs.
Also use WIN_POS_CENTER in the "ask about loading session" dialog.
(supplied order keys are correct).
This really shouldn't be needed, but historically there have been races
between the treeview and the editor order keys.
Interesting to note that there have been no reported ordering bugs when
loading sessions.
This is debatable, the "sustained until mouse release" behaviour is handy
sometimes, but this way seems like what most people probably want.
Also, this "fire it and forget it and let it delete itself a bit later" thing
with MidiPlayer makes me nervous. I guess it's unlikely someone manages to
select a note then delete a track within 100ms, but, well...
Fixes bug #6179. Top vs. bottom seems pretty arbitrary to me, and this solves
the obscuring issue (which is quite common since there are often PC events at
the start of MIDI files), so bottom it is.
Fixes bug #0006138. This solution does make the other label move when settings
are changed (presumably what the fixed width stuff was for), but I don't think
this is a big deal. Lesser of two evils, at least.
Fixes a hack where it's transient parent was used to give an order hint
(for the order key of any new tracks).
This commit adds a new combobox "insert_at" to let the user tell us
where they want new tracks to go.
In the past, we chose different defaults in homage to ardour's old mix/edit groups.
But that wasn't a very good idea.
For now they have all properties enabled and the user can disable them as-needed.
It might also be nice to make the user's property selections perist for new groups.
Connect signal_button_press_event of 'Tap Tempo' button rather than
signal_clicked so we can use the time member of GdkEventButton to calculate
the tapped tempo. It seems to me that this is the right thing to do.
Add a function TempoMap::meter_section_at(), similar to
TempoMap::tempo_section_at() but returning the meter section at the given
position, and use this to make editing meter changes from the main clock
work on the meter that's in effect at the current position.
Remove (always false) duration & is_transient and (always true) editable,
with_info & follows_playhead parameters from MainClock constructor, and just
pass the requisite true & false values along to the AudioClock constructor
instead.
1) When changing the 'Default folder for new sessions' we weren't responding to the appropriate signal (so the change wasn't getting saved in our user's 'config' file). We now respond to the 'selection-changed' signal.
2) If the above path happened to contain a tilde character we weren't interpreting it to mean the user's home folder. I've copied across a function called 'poor_mans_glob()' which Ardour uses elsewhere for dealing with this situation in other file dialogs.
Once we confirm that issue #2 is now working for all platforms, I'd suggest moving 'poor_mans_glob()' into libpbd. At the moment we have at least 3 definitions of it (all identical) scattered around in various places.
sets transient windows to be transients for the front window when switching
between the editor and mixer. This is the current behavior on non-osx
builds.
When disabled, there is no reparenting of transient windows. This is the
current behavior on osx.
This preference defaults to off.
Also fix "all windows are dialogs" checkbox being out of sync with the ui
state.
maybe this should be an option? So far it’s
the matrix only.. gotta start somewhere.
PS. No, this is not a new feature. Ardour not doing this
is a major bug that severely reduces usability:
system:midi_capture_47 WTF? ;-)
Before this, LV2 preset deletion in Ardour was doubly broken: the wrong file
was being removed, and removing the correct file would only result in a broken
preset. This change uses a new version of Lilv which has a more sophisticated
mechanism for preset deletion.
Also, fix "clashing" presets saved with the same name for different plugins, by
prefixing the plugin name to the bundle (this is now a recommendation in the
LV2 preset specification).
Several reasons:
* This previously looked horribly inconsistent.
* The Gtk selector was broken for plugins with many presets,
making it impossible to select presets. For whatever reason,
the use of a menu fixes this bug.
* Towards a hierarchical menu for banked presets.
Previously the region was nearly invisible when editable which is
problematic ("oops, I made a new region"). The distinction isn't quite as
profound as it probably should be, but I don't want to mess with the other
region colours too much.
This avoids stuck notes if active notes are edited, but without stopping all
active notes in the region on any edit as before.
This implementation injects note ons in places that aren't actually note
starts. Depending on how percussive the instrument is, this may not be
desired. In the future, an option for this would be an improvement, but there
are other places where "start notes in the middle" is a reasonable option. I
think that should be handled universally if we're to do it at all, so not
considering it a part of this fix for now.
When the GUI is opened the first time all is fine, focus is on the
embedded widget. However once a user presses one of the preset buttons
(Add, Save,...) there is no possibility to return focus to the
embedded widget. Ardour always 'sees' it as focus=GtkButton and passes
the event to the editor.
This probably breaks some of ardour's functionality (e.g. layered mode), but seems to
be either just right or very close to it for tracks
Conflicts:
gtk2_ardour/editor_routes.cc
This does not address the visual flattening that occurs before the drop
is complete. Doing that is complex and there is no immediate solution
visible. The result after the drop is complete is correct, however.
Pass 'ignore_playhead == true' to Editor::get_preferred_edit_position()
when calculating offset of the primary and secondary main clocks if 'delta
to edit cursor' is selected, so that if the edit point is playhead, the
selected marker (if any) or mouse position will be used as the delta origin
instead.
Remove the is_xrun parameter from Editor::mouse_add_new_marker(), and just
create the marker directly in ARDOUR_UI::create_xrun_marker(), so that xrun
markers don't become automatically selected when they appear.
