“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.
