This fixes an issue with
* XMLNode::get_property(const char*, T&)
* XMLNode::set_property(const char*, const T&)
resulting in
string_convert.h:77: error: 'long int' is not a class,
struct, or union type
buffer-size = periods * period-size
Previously, buffersize was used for period-size.
This fixes an issue with a dedicated .asoundrc configuring a specific
period-size or buffer-size that has to be exact.
Ardour's device configuration failed in this case.
This has not been an issues since most hardware devices offer a wide
range: 8 < period-size < 262144 ; 16 < buffer-size < 524288.
Only a subset of which (32 .8192) is allowed by Ardour.
This will allow to create a PNG of all mixer-strips, even those currently
off-screen due to scrolling. It currently shows the main scroll-pane
page only (master-bus, VCAs are not included).
This method is not yet exposed.
Without an object, the Unwinder has no scope and the "ignore" variable
is never set.
In this case: When the patch-bank was changed externally this
lead to a duplicate recursive call to "refill_banks".
Previously only manual changes of the note-range using the scroomer.
The NoteRangeChanged() was ignored for implicit changes (e.g. while
recording, step-entry) and automatic-fit that didn't involve a drag
event.
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.
