This test seems to be compiling and passing just fine (when run in
isolation), so turning it back on seems like a good idea. To make it
pass when run as part of the full ardour test suite, this does remove
the WebSockets control surface from the control surfaces test though, as
that control surface messes up the event loop of the main thread, which
would otherwise cause use-after-free crashes in the session test.
This also fixes a potential buffer overlow on Windows.
Window _snprintf does not null terminate the string in case
the formatted length is longer than the given buffer size.
http://msdn.microsoft.com/en-us/library/2ts7cx93%28v=vs.110%29.aspx
(mingw's uses _vsnprintf under the hood which is also affected).
Alternatively we could rely in g_snprintf() to truncate the
string.
Session::setup_bundles() creates mono and stereo bundles from hardware
inputs and outputs. For mono bundles the name of the bundle was based on
the pretty name of the port (if the port has a pretty name), however
stereo bundles always used the indices of ports to make the name.
When using pipewire (or otherwise having multiple jack clients exposing
physical ports) the indices are even less meaningful than otherwise (as
different devices could appear in arbitrary order), so also using pretty
names for stereo bundles makes the UI less confusing in places where
these bundle names are used (for example the menu when clicking on an
IOButton).
Previously AudioPlaylist::read always returned the timecnt that
it was supposed to read into the buffer, regardless if the given
number of samples was read. The check in DiskReader::refill_audio
`if (nread != to_read)` never triggered.
This can happen when changing an audio-region's time-domain to
music-time (glue to bars/beats). Region-length (beats converted
to samples) can exceed the actual audio-source length (in samples).
AutomationList::start_touch must not start a write-pass.
That function is also called when the transport is no rolling.
A write-pass is started via AutomationWatch::add_automation_watch.
This fixes a crash when deleting routes, while there are still
automation events queued for the route.
Specifically, SoloControl has a reference Soloable& _soloable; which
points to the parent route. A rt-event can still hold a valid shared
pointer to the SoloControl, even if the route is destroyed.
Calling SoloControl::actually_set_value is fine (the control still
exists due to the shared ptr), but then checking the parent route:
```
if (_soloable.is_safe() || !can_solo())
```
accesses the already deleted route, which causes a crash.
The solution implemented here is to not bind a shared_ptr to the
realtime event. However, since deletion of the route happens in the main
UI thread, there may or may not still be a race.
In practice, this mostly means integers when presets leave off the ".0", but we
implement all the numeric types here for good measure.
Also while we're at it, warn about unknown types now so it doesn't take three
people a half an hour to figure out what's going on the next time something
like this happens.
This disables the feature added in 057fd9259e.
The idea was to use double-click to reset the fader (like
Harrison consoles). Simply re-select can lead to accidents.
We cannot call TempoMetric::superclock_at (BBT_Time) if the BBT time is beyond
the range of the current TempoMetric. We must discover that *before* we make
that call, not as part of the test to see if we've exceeded the range.
