This allows the clear methods to be used before calling ::add(), to avoid the
emission of a signal saying "there are no <foo> selected right now".
There should be no side-effects from this commit.
Note that correct use of this new API is complex, and requires avoiding the use
of wrapper methods like clear_objects().
Each MidiRegionView(MRV) is connected to the Selection::ClearMidiNoteSelection
signal that is used to notify the all MRV instances to clear their note
selection.
The MRV class also has a private static SelectionCleared signal that is used to
signal other MRV instances when their selection has been cleared. When the
Selection::ClearMidiNoteSelection signal is emitted it causes each MRV to also
emit the SelectionCleared signal. So the emission takes quadratic time.
With 1500 MRV instances emission takes about 2.2 seconds on my machine, and
some operations like track selection cause it to be emitted 3 times(another
issue).
The Selection class in the Editor knows which MRV instances have note
selections, as it is notified by MidiRegionView whenever the selection count
becomes zero or becomes non-zero. Clearing the Note selection should then just
be O(N) and direct calls can be used rather than signals.
This change removes both the signals and uses the existing references between
Selection and MRV class to control note selection. There should be no
behavioural changes in Midi note selection with this change.
- disallow simultaneous events via ControlList::editor_add ()
- clicking on an automation line selects the points that define it.
- don't 'flash' a region selection when using mousedraw mode.
- cp click selection resembles region selection.
- region gain points respect snap modifier (a la automation points).
Fix several other cases where a single mouse click could cause several
(not nested) selection ops.
Fix missing selection memento for midi notes and midi commands.
Rename some variables.
Fix random style issues.
The user can now replay *all* earlier selection operations until the next
session undo/redo command, or the completion of a new operation.
Nothing relating to selection ops is stored, and selection operation history
is begun on first idle.
Selection operation history is fundamentally different from the history of
operations which act on a selection in terms of both their viewport and the
amount of information required to replay them.
WRT undo, the user of a selection op doesn't care about the viewport state
at the beginning of an op, but rather that at the end of the previous one.
combines selection related editor properties with the current editor selection.
The related editor properties are:
mouse mode,
zoom setting,
left frame of the canvas,
y origin of the canvas.
Selection state now includes region views (storing the underlying region id)
and time.
This patch also fixes a region mute undo bug.
Among other things, this means that automation controls/lists have the actual
min/max/normal/toggled of parameters, and not those inferred from the Parameter
ID, which is not correct for things like plugin parameters.
Pushing things down to the Evoral::ParmeterDescriptor may be useful in the
future to have lists do smarter things based on parameter range, but currently
I have just pushed down the above-mentioned currently used attributes.
The idea here is to do the reasonable thing, and copy objects of some
type (e.g. MIDI region, gain line) to tracks with a matching type. The user
can override this with a track selection, which will be used straight-up.
Lost: ability to copy/paste lines across types, e.g. gain to pan. This is
often questionable, but sometimes useful, so we will need to implement some
sort of "greedy mode" to make it possible. Implementation simple, but not sure
what to do. Perhaps this should only be possible if one automation track is
explicitly (i.e. via track selection) involved, and the types are at least
compatible-ish?
This cleans up a lot of false-positives in static analysis
and also helps compilers to optimize code paths in general.
(tagging the fatal stingstream operator as ‘noreturn’ is
far less trivial)
unselected when you ctrl-drag a selected point in order to
do a push drag.
git-svn-id: svn://localhost/ardour2/branches/3.0@12502 d708f5d6-7413-0410-9779-e7cbd77b26cf
rather than a time range. This makes more sense now that we
display every point on an automation line, rather than just
a subset. Makes the code a fair bit simpler, and should fix
some unexpected behaviours, especially when cutting automation
points.
git-svn-id: svn://localhost/ardour2/branches/3.0@12054 d708f5d6-7413-0410-9779-e7cbd77b26cf
applies to the selected tracks. Some tinkering with how tracks are selected
during time selections.
git-svn-id: svn://localhost/ardour2/branches/3.0@6360 d708f5d6-7413-0410-9779-e7cbd77b26cf
simplify code related to selecting tracks. Add a TrackViewList object rather than
"abusing" TrackSelection in lots of places.
git-svn-id: svn://localhost/ardour2/branches/3.0@6358 d708f5d6-7413-0410-9779-e7cbd77b26cf
Vimmers, try let c_space_errors = 1 in your .vimrc to highlight this kind of stuff in red. I don't know the emacs equivalent...
git-svn-id: svn://localhost/ardour2/branches/3.0@5773 d708f5d6-7413-0410-9779-e7cbd77b26cf
- Split Configuration into RCConfiguration and SessionConfiguration;
the first for options which are saved to .rc files and the second
for options which are saved in a session file.
- Move some options from the old `master' Configuration object into
SessionConfiguration; this needs more refinement.
- Reflect many RCConfiguration options in an expanded Edit->Preferences
dialog; my intention is to remove the corresponding menu items
eventually.
git-svn-id: svn://localhost/ardour2/branches/3.0@5075 d708f5d6-7413-0410-9779-e7cbd77b26cf
All #include statements that include a header that is a part of a library
bundled with ardour MUST use quotes, not angle brackets.
Do this:
#include "ardour/types.h"
NOT this:
#include <ardour/types.h>
Rationale:
This is best practice in general, to ensure we include the local version
and not the system version. That quotes mean "local" (in some sense)
and angle brackets mean "system" (in some sense) is a ubiquitous
convention and IIRC right in the C spec somewhere.
More pragmatically, this is required by (my) waf (stuff) for dependencies
to work correctly. That is:
!!! FAILURE TO DO THIS CAN RESULT IN BROKEN BUILDS !!!
Failure to comply is punishable by death by torture. :)
P.S. It's not that dramatic in all cases, but this (in combination with some
GCC flags specific to the include type) is the best way I have found to be
absolutely 100% positive the local ones are being used (and we definitely
want to be absolutely 100% positive on that one).
git-svn-id: svn://localhost/ardour2/branches/3.0@4655 d708f5d6-7413-0410-9779-e7cbd77b26cf
Anything related to the storage of events/values over a range of time lives in evoral.
This includes MidiModel (Evoral::Sequence) and automation data (AutomationList (Evoral::ControlList),
Automatable (Evoral::ControlSet), etc).
libs/evoral synced with http://svn.drobilla.net/lad/trunk/evoral r1511.
git-svn-id: svn://localhost/ardour2/branches/3.0@3754 d708f5d6-7413-0410-9779-e7cbd77b26cf
