I'm not sure why exactly but at this line in 'GainMeter::set_controls ()' :-
model_connections, invalidator (*this), boost::bind (&GainMeter::redraw_metrics, this), gui_context()
MSVC will not allow us to pass a base class function to boost::bind(). I tried explicitly specifying the base class and I also tried making the function public / making it virtual etc but the only thing which works is to implement a derived function.
It's somehow related to changing the signal from 'TypeChanged' to 'MeterTypeChanged' but I don't entirely understand why... :-(
Ardour's Tracks/Routes are not capable of handing more than one
MIDI port per per route properly. Most Plugin standards don't support
this either.
However, at this point in time IO::ensure_ports_locked() is not
limited by this restriction!
It is still possible to indirectly add a 2nd MIDI data-buffer
and output-port via plugin pin-management, or simply plugins with
two MIDI output ports when using flexible I/O.
* Allow to exit cleanly (using access-action)
* Terminate when the backend is halted
* Handle various commandline arguments as advertised
- print version
- disable hardware optimization
- set client-name
- prevent port-connections
* Use JACK -- previously hardour only worked if
Ardour was compiled with JACK as *only* backend.
Other backends are listed before JACK, set_default_backend()
never picks JACK unless it's the only one.
Other backends need configuration, or EngineState from config.
This is currently handled in the GUI's engine-dialog..
This fixes an issue with inconsistent startup scripts.
LD_LIBRARY_PATH was incomplete since at least 5.0 (5.12 is broken, too)
likewise ctrl surface path were outdated, etc.
Prefer to use `gtk2_ardour/ardev_common.sh.in` as the central
point to define environment variables for running Ardour from
the source-tree.
Other start scripts e.g. `vst/ardevst` already did this.
NB. this is just as unused as the POSIX link() test. Aardour
doesn't create hardlinks since version 3.0. At least it's now
consistently wrong on all platforms :)
This removes all additional GUI side meter-type state.
The route's meter-processors is now responsible for providing
the type.
meter-type is now implicit for GainMeter, LevelMeter used by
meter-strips and mixer-strips.
In theory different UIs can show different meter-types, so it
can make sense to maintain the type in different places.
MeterType is a bit-set and PeakMeter implementation provides for this.
However, this is not being used, and the current implementation
was rather fragmented, cross-connected signals to keep types in sync,
allowed inconsistent meter-types in GUI and backend.
MeterType is now kept by meter itself, however it is still
saved/restored as part of the Route state.
N.B. This change breaks the API, various methods have been renamed
for consistency.
