* 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?
When bouncing Region or Range, Session::write_one_track()
blocks processing, but takes no process-lock.
It is possible that a latency-callback arrives at the same
time while Route::bounce_process is active and calls ::run.
This can trigger a delayline.cc Assertion `lm.locked ()' failed
in either thread.
Now latency-callbacks are postponed until the session can
process normally again
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.
process_index should not be compared/combined with expected_end_sample, since
the former is a process-cycle count and the latter is a timeline position.
* first the region is scanned for bpm and one-shot status
* then we handle properties that should be applied from a drag&drop
* then we handle the existing arrangement-style slot properties that should persist
This should not be needed, however Editor::idle_remove_tracks()
has the same priority as Editor::redisplay_track_views() and this
might save us another redisplay call.
There is probably a good reason why _vca.reset() is called
immediately, and 6dc66ea78f is a better solution to the issue
This reverts commit 83719fba1a.
This addresses the issue described in 83719fba1a.
First process all queued self_delete() requests before scheduling
Editor::redisplay_track_views() which uses PRIORITY_DEFAULT.
Session::remove_routes() first calls IO::disconnect()
before eventually calling route->drop_references().
RouteTimeAxisView::io_changed() is called while the route still
exists and requests a redraw which in turn emits
_stripable->gui_changed ("track_height").
Since the RTAV is deleted later during an idle-callback, there
was another redraw performed just before the RTAV is actually deleted.