Unfortunately we store the state of models as simply model, so if there's ever
duplicate model names, we're somewhat screwed, but this makes the (previously
unmanageably huge) menu usable, while retaining the "model name as global
identifier" state unmodified.
Preserve alignment between notes and control points when doing an internal
copy/paste of both.
Relative alignment between points on multi-paste is still not preserved. Both
behaviours here are actually useful, perhaps a modifier...
Perhaps debatable if contents should be edited when not in internal mode
whatsoever, but consistent with audio region gain and track automation. It's
less of a problem with the draw tool than, say, object since drawing stuff is
its entire purpose.
When entered, the keyboard is grabbed when the selection becomes non-empty, and
ungrabbed if it becomes empty again or the region is left or the user switches
out of internal mode.
This fixes scroll in internal mode and note moving with arrow keys. Also frees
up useful keybindings when there is no note selection, which is much nicer than
the "nothing works in edit mode at all" greedy grab approach used previously.
Attempt #874327892 of getting this damned grabbing right.
This doesn't seem to have been touched for years, and I don't see how such an
obvious bug could possibly have been around for so long, but, well, this fixes
it as far as I can tell.
I am not sure what causes this, but it can happen when finishing a record
sometimes. Probably MidiSource::_writing isn't updated in the right order with
whatever triggers the redisplay, but at least not crashing is better...
For things like copying from pitch bender to a CC.
Also things like fader to pan, but that seems a bit funny. The conversion
probably needs to be a bit smarter here, perhaps taking the normal into
consideration...
Also push the increasingly unwieldly paste parameters into a context object.
As with othe things, currently it is only possible to do "cross-type paste" by
explicitly selecting the target track. We will need to get automation region
view selection working to do better here, but at least for now it's possible to
get the data over.
For some reason, grabbing the magic keyboard focus makes scroll stop working
regardless of what MRV::canvas_group_event() returns. I can't figure out any
reason to grab the keyboard in this case anyway, so I just removed it.
Also simlify MRV event handling code in general.
Shoot for roughly 30 steps for all controls.
Always keep sensible step information in ParameterDescriptor and just convert
for the UI.
This is a little weird, but it's less weird than it was before, and works.
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.
fixes crashes:
* If the Editor-Mixer shows a channel with a plugin that
has been edited in the Mixer, double-clicking the plugin
will try to bring up a 2nd instance of the plugin-UI.
* When closing Ardour both the Mixer and the Editor-Mixer try to delete the underlying plugin, resulting in a double free.
This probably isn't correct in several ways, but it works more than it did, so
I figure it's push worthy.
Still not working:
* Saving mute automation list
* Dragged control points are not snapped to model restrictions
(boolean, in this case, but general problem)
* Line goes funny if you record mute automation
(as opposed to drawing it which works)
This is pretty kludgy but we need the UIConfiguration object (or any color management object) to be the first to connect to
the ColorsChanged signal.
Might be better to make the UIConfiguration object a delegate for the ThemeManager.
Using _last_pointer_frame breaks when dragging to the left of the canvas, because we clamp
the value of the frame to >= 0. Motion would step once the pointer crossed the left edge
of the canvas because the frame value would always be zero.
This is not a problem when using the pointer x,y values which end up appropriately negative
under all conditions.
* ifdef unused static functions
* brackets around assignment and comparision
* no return statement in function returning non-void
* boost concept_checks.hpp unused-local-typedefs
This lets us get a more explicit handle on time conversions, and is the main
step towards using actual beat:tick time and getting away from floating point
precision problems.
cursor icons squared with north-west gravity.
hotspots are identical to original icons.
otherwise gdkcursor-win32 creates square cursors with
center gravity and hotspot X/Y differs.
Fix some inaccurate/misleading comments that led to said bug.
Gracefully handle the "impossible" case where we can't figure out a state ID
for an automation track, instead of crashing.
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 should probably hijack the same modifier as the guard points and work the
same on all automation tracks, but I did it this way to not change behaviour of
track automation where a default is much more reasonable.
No functional changes in this one (for easier auditing), but towards having
round up/down only if necessary modes, rather than kludging around that
situation with a double round as we do currently.
We shouldn't have to manually drive the drag here, but if the ARV handler
returns false, the event doesn't propagate correctly for some reason and the
drag is not driven by the Editor.
Two issues:
1) AutomationRegionView not receiving events (CC breakage).
2) Entered values must be rounded to integer for MIDI controllers. This should
be done more generically with ParameterDescriptor for all controls (also
supporting boolean toggles and such), once ParameterDescriptor becomes more
pervasive and takes over Evoral::Parameter, but this will do for now.
It was much too easy to accidentally create MIDI regions in object mode. If
the user isn't in draw mode anyway, then even after creating a region, they
can't put notes in it, so I don't think we've lost any discoverability here.
The idea here is that pasting several times to the same location doesn't make
sense. Instead, the paste is appended past the last paste, snapped to the
grid. This make it simple to replicate a given section a number of times,
simply by copying once and pasting several times.
This behaviour only appears when successive pastes are done to the same
location (whatever the edit point is). When the paste point changes, the
"multi-paste" state is reset.
Boots 'n cats 'n boots 'n cats.
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)
Specifically, when pivoting from forwards to backwards (around the drag start
point), the note length was too long. Setting both the start and end x
coordinates of the rect every time to the right value does the right thing.
This makes for extremely confusing behaviour, particularly when creating new
regions. This is still probably too transparent, IMO, but at least isn't
totally mysterious. "visible" is a bit of a misnomer in the code, now.
Use RegionSelection for MIDI regions as well, since the old dumb stub didn't do
some things correctly. There's probably no reason to have a separate class for
this at all, and some good ones for putting all regions in the same selection,
so we should probably do that. For now they are still separate in the
selection but use the same base class.
Show fancy values on generic GUI controls, automation lane controls, and automation lane verbose cursor.
Fix text display of midiNote values.
Make bigstep of midiNote parameters 12 (one octave).
Add ARDOUR::value_as_string() as a stateless one-stop-shop for value printing.
Prepare to allow BarController (with Spinbutton) to translate
internal/interface values for the SpinBox.
(The change is irrelevant for the fader/slider itself which
always use the [user-]interface value)
