This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
In layered mode the scroomer is not usable with stacked MIDI regions.
Ideally we'd only hide it if there is more than one layer
but that is for another day.
When adding a note, use these criteria to choose the channel number:
* if the user has explicitly specified a note in the pulldown, use that
* if the user has AUTO selected and we are in a region, choose the nearest note's channel (consistent with velocity behavior)
* as a fallback, query the track for its channel-filter (old behavior)
This supersedes 0708cdb6b4, an explicit `name_label.show()`
is not needed. The inactive label was missing an explicit call
to show.
This also fixes MIDI track MIDNAM Selector visibility
This removes various duplicate code-paths leading to midi-model
updates, and expensive context-menu rebuilds. This significantly
speeds up MIDI track creation.
* Always use InstrumentInfo for lookups.
Remove name lookups that directly used gui_property()
* Use set/get_gui_property() only to save/restore state,
push custom selection to InstrumentInfo.
* Only store custom selection, use unset for "default"
default = plugin-provided (if available) otherwise general-midi
Most of Ardour's GUI queries route->instrument_info() for MIDNAM.
This is a minimal invasive hotfix to update the PatchChange
dialog and patch-names on the timeline when the MIDNAM selection
changes.
This got lost in de74cca6b8.
If there's no GUI property for the MIDNAM model name, and the plugin has no MIDNAM, there's no reason to set the property to the default
It will pick up the default ("Generic") during update_patch_selector() calling into model_changed
Attempt to re-use GUI property for MIDNAM device mode, and if it doesn't exist, use the first from the model's device mode list.
Also require at least one device mode in the MIDNAM file (via assert) - consider anything else to be malformed
We do not store the MIDNAM model as a GUIObject property if the using the plugin-provided MIDNAM. Selecting a different MIDNAM for
the plugin should now result in that choice being saved/restored correctly.
This all feels crazily complicated, but I don't want to change more of the architecture at this time
Paul Davis
Robin Gareus
luz paz
Ben Loftis