Change ruler context actions from "Make Loop range" to "New Loop range"
change ruler context actions from "Make Punch range" to "New Loop range"
This to make it consistent with other ruler context actions eg. "New....."
Copy the 'Cut time' code from Mixbus, making a few obvious fixes to work in
A3 (e.g. nframes_t => framepos_t / framecnt_t).
Seems to work to move & remove markers, tempo & meter markers, and regions on
selected tracks.
Still TODO:
- use existing A3 'Insert time' dialogue
- make it respect 'No selection = all tracks'
- rename the command to something like 'Remove time' or 'Delete time': 'Cut'
sounds to me as if the removed range should end up on the clipboard ready
to be pasted somewhere, which of course it doesn't.
[Details] This bug does not show up when buffers are 16 byte aligned, but when they are not - this bug will lead to crash.
I tested all these functions with non-aligned buffers as well as long they do handle the situation with unaligned buffers.
[To be reviewed by] Paul Davis
see man 3 dlopen. Ideally we’d use RTLD_DEEPBIND,
but it’s neither portable and rather new (glibc 2.3.4).
This fixes issues with symbol conflicts in plugins
e.g. http://pastebin.com/FkFkf3Mm (plugin expects
its own OSC[illator?] class but gets ardour’s
OpenSoundControl instead).
towards fixing #6238 and #6096.
GUI thread:
#2 Glib::Threads::Mutex::Lock::Lock
#3 Evoral::ControlList::eval
#4 Evoral::Control::get_double
#5 ARDOUR::AutomationControl::get_value
#6 ProcessorEntry::Control::control_changed
..
#15 PBD::Timer::timeout_handler
at the same time: Audio Thread (try-lock, fails)
#0 Evoral::Curve::rt_safe_get_vector
#1 ARDOUR::Amp::setup_gain_automation
#2 ARDOUR::Route::process_output_buffers
Due to the failed try-lock.. AMP::_apply_gain_automation
is false. and Amp::run() uses a different gain factor.
-> click.
For some reason we don't understand 'push_state_to_backend()' can interfere with hiding the dialog (causing a partially hidden dialog to remain on screen). It's most likely a timing issue with the Windows version of GTK. Fortunately, reversing the calling order seems to fix it - BUT...
If there's no session loaded yet, the user can be left with a very long wait while nothing seems to be happening. The next thing the user would normally see would be the splash image. So let's display it slightly early (so the user can at least see that something's happening).
Sadly, it's all very kludgy - but a lot better than what we had before... :)
