This may (or may not) fix#8317. Usually changing I/O triggers
an auto-connect. The actual issue seems that auto-connect
thread runs before the ports are created.
This significantly speeds up parsing MIDI files with complex
tempo-maps. e.g. "Black MIDI Trilogy_2.mid" has 24134 Tempo
changes. Prior to this commit parsing that file took over 5 minutes.
now it loads in under one seconds (libsmf only; libardour still
add overhead, and now needs about 30-40 seconds, previously
it took about 10 mins).
The problem was that every call to `smf_track_add_event_pulses()`
calls `seconds_from_pulses()` which calls `smf_get_tempo_by_seconds()`
which iterates over the tempo-map:
for every midi-event { for ever tempo until that midi-event {..} }
This does not scale to 3.5M events and 24k tempo-changes.
see also https://github.com/stump/libsmf/pull/7
* Fix validity checks of escaped data
* Handle non-EOT-terminated tracks.
* Fix buffer overflow on tempo change event
* Fix memory leaks in case loading fails
* Fix a logic errors in extract_escaped_event()
* Fix the assertion problem `is_sysex_byte(status)`
* Make libsmf more tolerant to malformed MIDI files.
(fixes import of files generated by NoteEdit)
https://lv2plug.in/doc/html/group__options.html specifies
a NULL terminated array of options (not a single option).
Since the call is the "instantiation" LV2 threading class, and
a single fixed value is passed with a direct call into the
plugin, using a stack-allocated LV2_Options_Option is sufficient.
This is only relevant with JACK, where different implementations
use threads for the latency callback.
With jack 2, jack_port_register() blocks and the jack_latency_callback
arrives in a different thread: https://pastebin.com/mitGBwpq
with jack 1 the callback arrives in sync
In either case this usually happens while
_adding_routes_in_progress == true and Ardour holds the process-lock,
because jack2 can process in parallel with reconfiguring latency
See also 1983f56592
When removing a plugin-insert that has a sidechain on a bus
that is implicitly soloed the following happens:
* Route::remove_processor() takes a WriterLock(_processor_lock)
* The sidechain input is disconnected
* Route::sidechain_change_handler() is called which calls
* Route::input_change_handler()
* Since the route is implicitly soloed, propagation is attempted
which calls
* Route::direct_feeds_according_to_reality()
which takes ReaderLock(_processor_lock)
Recursive locks, reader-lock after writer-lock don't cause
a deadlock, releasing the reader-lock effectively also
releases the writer-lock...
Polygons used PolyLine::render() to render the path.
However since 7bb8ca1e76, the PolyLine path is constrained
(for automation lanes), and closed shaped polygons were not
always completely redrawn.
It is possible that Route::monitoring_state() returns
(MonitoringDisk | MonitorSilence)
This lead to various cases where there were is a direct comparison
(ms == MonitoringDisk). DiskReader::run tests for MonitoringDisk
to check if the buffer needs to be zeroed while locating.
Likewise Route::process_output_buffers() also explicitly tests
for both MonitoringDisk and MonitoringDisk.
The issue was likely introduced in fbe8075117 (although
it may have been possible in earlier version when using hardware
monitoring as well).
Previously add_remove_sidechain() released the process-lock
(to create the I/O ports), while keeping a processor writer-lock.
Meanwhile the auto-connect thread may be woken up to perform
a latency update. This thread takes the process-lock and
then stalls, waiting for a processor reader-lock.
Then add_remove_sidechain() continues and tries to re-acquire
the process-lock.
Previously the GUI explicitly called remove_preset() before
saving a plugin-preset. This functionality is now moved
into the backend.
This fixes a case when a user tries to save/replace factory presets
and works around https://github.com/lv2/lilv/issues/37
Register all plugin props that we may be interested in
to _property_values, and later intercept all messages for
registered properties (not just atom_Path).
This partially reverts 208c781248
in order to fix monitoring when using punch-in/out.
This also allows to revert to Ardour 5 style MIDI exclusive
Input or Disk monitoring when not using layered-recording.
The GUI uses ::axis_view_by_control() if a controllable when
the CoreSelection contains a controllable.
CoreSelection::get_stripables() saves and looks up controllable
by PBD::ID. Panorama automation controls were previously
not found, since they are not directly owned by the route.
AutomationWatch::transport_state_change() is called at a time
when transport has just started to roll, but may not yet be rolling
(count-in, latency-preroll).
Later, after pre-roll is complete and transport starts moving,
AutomationWatch::transport_state_change() is not called again.
Thus set_in_write_pass(true); is never called, and writing
automation assumes that all changes happen while stopped.
In 'write" mode, guard points are added for each change, when
the transport is stopped.
Before this change, this happened at periodic intervals even
when rolling.
Terminology used by server and client was starting to diverge.
C++ classes ArdourStrips and ArdourGlobals classes have been
renamed to ArdourMixer and ArdourTransport respectively.
State node values for transport functionality have been simplified
and prefixed with 'transport_' to match what was done for strips.
Replace previous callback based basic client with an easier
to use object-oriented API that further abstracts the low level
details of the WebSockets Server surface messaging protocol.
All built-in web surface demos were updated to use the new API.
LWS_WITH_EXTERNAL_POLL a new optional define for libwebsocket 4.x.
Earlier versions always supported it, without the compile-time define.
This fixes support for libwesocket 2.x (Debian, Ubuntu), and 3.x.
Also for Windows, LWS_WITH_GLIB is not available.
This is a glibc-only extension, so don't bother on other platforms.
Also, according to POSIX, PTHREAD_STACK_MIN is defined in limits.h, so
include climits just to be safe.
