This fixes various Lua-scripts: There are no explicit bindings to
turn int64_t, uint64_t into a const reference.
Besides it doesn't make sense to use a reference for constant _t that can
be directly loaded in CPU register or on the stack.
Remove various checks, add assert() for now (perhaps some old sessions?)
This fixes an off-by one issue when adding tracks (presentation
info order in add_routes_inner)
* requested_physical_in/out was unused
* input/output Autoconnect just overrides Preference/Config
(can be done by a template script)
* master_out_channels is kept for compatibility (allow to create
new empty session)
It isn't 100% clear that we should use the list's data lock, but it seems quite likely
that this is the correct design, because of the interlock between data being present
and automation state
Prepare for a method consistent with access_action():
* separate group + action names
* no action string parsing overhead.
* no fatal, abort () call for invalid actions
This hopefully fixes an issue with port-registration (new session)
being skipped because PortAudioBackend::available() still false
until the first callback.
The root-cause is likely PortAudio backend specific async
port-registration, re-establish ports after session creation and
after the first callback and it's apparently a race-condition:
crash is not 100% reproducible.
#10 0x00007ffb156df18a in msvcrt!abort () from C:\Windows\System32\msvcrt.dll
#11 0x0000000012597832 in _wassert (_Message=_Message@entry=0x2eaf96f0 L"_port_handle",
_File=0x2 <error: Cannot access memory at address 0x2>, _File@entry=0x346a1430 L"../libs/ardour/audio_port.cc",
_Line=80) at ../../mingw-w64-crt/misc/wassert.c:54
#12 0x00000000125978e8 in _assert (_Message=0x1282f7e9 "_port_handle",
_File=0x1282f7a0 "../libs/ardour/audio_port.cc", _Line=80) at ../../mingw-w64-crt/misc/wassert.c:30
#13 0x00000000120d1a51 in ARDOUR::AudioPort::get_audio_buffer (this=0x34a95a70, nframes=256)
at ../libs/ardour/audio_port.cc:80
#14 0x00000000126724f9 in ARDOUR::AudioPort::get_buffer (this=<optimized out>, nframes=<optimized out>)
at ../libs/ardour/ardour/audio_port.h:43
#15 0x0000000012435421 in ARDOUR::Session::ltc_tx_send_time_code_for_cycle (this=this@entry=0x37666310,
start_frame=0, end_frame=end_frame@entry=256, target_speed=0, current_speed=0, nframes=nframes@entry=256)
at ../libs/ardour/session_ltc.cc:180
#16 0x000000001245209f in ARDOUR::Session::no_roll (this=this@entry=0x37666310, nframes=256)
at ../libs/ardour/session_process.cc:145
#17 0x0000000012453051 in ARDOUR::Session::fail_roll (this=this@entry=0x37666310, nframes=<optimized out>)
at ../libs/ardour/session_process.cc:128
#18 0x0000000012459ebd in ARDOUR::Session::process_without_events (this=this@entry=0x37666310,
nframes=nframes@entry=256) at ../libs/ardour/session_process.cc:897
#19 0x000000001245a462 in ARDOUR::Session::process_with_events (this=0x37666310, nframes=256)
at ../libs/ardour/session_process.cc:425
#20 0x0000000012451bc5 in ARDOUR::Session::process (this=0x37666310, nframes=nframes@entry=256)
at ../libs/ardour/session_process.cc:78
#21 0x00000000120e79fd in ARDOUR::AudioEngine::process_callback (this=0x23316e30, nframes=256)
at ../libs/ardour/audioengine.cc:376
#22 0x00000000285390fe in ARDOUR::PortAudioBackend::blocking_process_main (this=this@entry=0x29e67750,
interleaved_input_data=interleaved_input_data@entry=0x115e8790,
interleaved_output_data=interleaved_output_data@entry=0x115e0050)
at ../libs/backends/portaudio/portaudio_backend.cc:1962
#23 0x0000000028539b75 in ARDOUR::PortAudioBackend::process_callback (this=this@entry=0x29e67750, input=0x115e8790,
output=0x115e0050, frame_count=<optimized out>, timeInfo=0x3d17fd70, statusFlags=statusFlags@entry=0)
at ../libs/backends/portaudio/portaudio_backend.cc:775
#24 0x0000000028539c16 in ARDOUR::PortAudioBackend::portaudio_callback (input=<optimized out>,
output=<optimized out>, frame_count=<optimized out>, time_info=<optimized out>, status_flags=0,
user_data=0x29e67750) at ../libs/backends/portaudio/portaudio_backend.cc:721
#25 0x00000000632c528f in NonAdaptingProcess () from C:\Program Files\Mixbus32C-4\bin\libportaudio-2.dll
#26 0x00000000632c73b2 in PaUtil_EndBufferProcessing () from C:\Program Files\Mixbus32C-4\bin\libportaudio-2.dll
#27 0x00000000632d129c in ProcessingThreadProc () from C:\Program Files\Mixbus32C-4\bin\libportaudio-2.dll
chicken/egg:
Stripable d'tor which calls remove_stripable_by_id() will only be called
when the Stripable is destroyed. But as long as the GUI selection holds a
shared-ptr reference to the Stripable, it won't be destroyed.
This fixes MIDI Input follows MIDI track selection (and maybe other
issues) and hopefully breaks nothing else (most places subscribe to
both Stripable::PropertyChanged and PresentationInfo::PropertyChanged).
Should fix a race during Session::destroy(), Port::PortDrop
which unregisters ports with the backend, but the actual port instance
will still exist.
The engine does no longer have a session-pointer and only calls
CycleStart(); CycleEnd() to clear port-buffers. Trying to clear
and already unregistered Port will crash.
- Control-protocols may transmit data during cleanup
(e.g. reset surface), and need the Audio-engine to do so.
- destroying the ControlProtocolManager w/o the Session calling
::drop_protocols(), lead to a double free.
Fixed a crash if an x-run or graph-reorder happens after the LTC encoder
has been destroyed (possible at session-close or after disabling
the encoder). This also fixes duplicate callbacks in case the
encoder was re-enabled times in an active session.
If the width of the display area is below 200 px, we switch from the graph
display to displaying only two bars, one for output level and one for gain
reduction. In the bar mode we also visualize threshold and ratio.
When lifting the compressor curve by the makeup gain value the actual
treshold (the level when the curve kinks in) is also lifted. Therefore we need
to adjust the dashed line indicating the threshold as well as the level when
the color gradient to show compression kicks in.
This fixes a crash with GUI elements which are only deleted during GUI
Idle and hold a Reference to a Controllable,
The session is already destroyed at that point:
ARDOUR::CoreSelection::remove_control_by_id(PBD::ID const&)
ARDOUR::AutomationControl::~AutomationControl()
ARDOUR::SlavableAutomationControl::~SlavableAutomationControl()
ARDOUR::MonitorControl::~MonitorControl()
boost::detail::sp_counted_base::destroy()
boost::detail::sp_counted_impl_p<AudioGrapher::Interleaver<float>::Input>::dispose()
boost::detail::sp_counted_base::release()
boost::detail::shared_count::~shared_count()
boost::shared_ptr<PBD::Controllable>::~shared_ptr()
boost::shared_ptr<PBD::Connection>::~shared_ptr()
ArdourWidgets::BindingProxy::~BindingProxy()
ArdourWidgets::ArdourButton::~ArdourButton()
VCAMasterStrip::~VCAMasterStrip()
int idle_delete<VCAMasterStrip>(VCAMasterStrip*)
Ardour follow_slave() does nothing (not even seek) if the slave is not
locked.
The LTC-slave assumes it's locked if LTC is stable for 5 continuous
process-calls.
If the difference of Ardour's transport-position to the LTC-timecode
is large (> 2sec), the slave reset itself (assuming drift, seek don't vari-
speed).
A LTC-slave does reset does reset the locked counter.
Hence: If initially Ardour's transport differs > 2 sec and the buffersize
is small (many process-callbacks), the slave kept resetting itself
never informing Ardour that it locked to the external TC, and Ardour
never issued a seek.
* lock list when editing (prevent concurrent modification of insert
iterator
* don't add a guard-point if an event is already present between the
target and guard-point-position
* remove existing automation-events (old guard points) when
touching automation w/o change
* don't unset "new write pass" when not rolling
(fixes issues when not rolling but locating with write-enabled)
This calls for a unified API to invoke
Automatable methods ::transport_located() and ::transport_stopped()
on Stripables, rather than indirectly calling it via
Route::non_realtime_locate(), Route::nonrealtime_handle_transport_stopped()
Setting a tempo to 'Continue' via right click puts it in a permanent state
of continuing the previous section's end tempo (basically what
'Lock Continue' should have been). This can be disabled (unlocked) by
selecting 'Don't Continue'.
Remove the previous temporary 'Continue' function.
Reorganise menu to separate position lock style from more commonly
used functions.
It would be nice to change get_audio_buffer() to not set
AudioBuffer::_written to false (all but one other user of this API also
only get read-only data), but that requires chaning the rationale of the
underlying ::set_data() API.
Rule #89: The *owner* of each automation-control is responsible to
evaluate automation of automated automation-controls (and emit Changed()
signals to notify the GUI and slaved controls).
This can happen during run(), when the Processor evaluates automation
(eg. PluginInsert does that), but needs to regardless, every cycle.
Emit Changed signal for GainControl
This follow the same concept as PluginInsert: The Changed signal
is called on demand when evaluating automation.
Note: MuteControl already implemented this,
This removes the special case of boolean_automation_run().
Likewise this removes special-cases for actually_set_value() during
automation playback.
Template files reside in
.config/ardour5/templates/$(template_name)/$(template_name).template
We run through .config/ardour5/templates/ and find there the names of the
directories the .template-files are located in. These directory names don't
have a .template extension. So we shouldn't try to chop the non existing
extension of, because then we only modify template names with a '.' in them.
_processors = new_list; may drop the last shared-ptr reference.
This may deadlock in ~IO() for I/O processors or plugins with sidechain
inputs. It's been mostly a non-issues since the GUI usually holds a last
shared-ptr reference for a processor to be deleted, but that is
not always the case.
AudioRegion::set_fade_in() freezes the original ControlList, then
assigns a new one and thaws that.
Frozen state needs to be retained during assignment.
Related: The overloaded assignment operator in AutomationList
performed duplicate signal emission and didn't freeze the list.
And it's actually mostly moot. interface_to_internal maps
any range to 0..1.
The GUI could just hardcode min/max 0, 1 and steps 1/30, 1/300.
Except for controls that have explicit range-steps & ctrl surfaces.
Ardour may have ignored log-scale for parameters 0..N and allowed
writing '0'. Force those values into the valid range on session load.
Also mark the list as "needs sorting" which removes potential duplicates.
This reverts commit e9ee454ced.
This needs more work to preserve non-customized panners in existing
sessions. "user-panner" is only set if a user explicitly selects a
panner.
The midi_input_handler for the AsyncMIDIPort is connected to the
main event-loop. Events may still be delivered after the surface was
destroyed.
That by itself is not harmful, unless a given message produces a reply:
The _output_port is already gone, FaderPort8::tx_midi crashes.
When triggering Session::undo() or Session::redo() from a
non-GUI-thread (e.g. from a surface protocol) Ardour crashes if setting a
CairoWidget dirty due to a ENSURE_GUI_THREAD assertion. (see #7371)
By triggering undo by BasicUI::access_action() rather than by Session::undo()
we ensure that the GUI thread will finally call Session::undo().
So more like a workaround ... but better than crashing :)
The vast majority of errors reported by users as
"Cannot configure audio/midi engine with session parameters"
have nothing to do with engine-parameters.
Fix potential crashes in case fluid-synth runs into an OOM error,
and address a const-cast compiler warning.
Switch to track github repo (instead of sf.net git)
The drawing itself should be unchanged but much of the rest of the
implementation has changed. The WaveViewThreads and WaveViewDrawingThread
classes were added and allow multiple drawing threads.
The Item::prepare_for_render interface is implemented by WaveView to enable
queuing draw requests for the drawing threads to process as soon as the state
change occurs during Editor::visual_changer, which often means the images will
be finished by the time they are needed in WaveView::render. This can
significantly reduce total render time and also flickering caused by images not
being ready for display.
If the drawing thread/s cannot finish the request by the time it is required in
WaveView::render then cancel it and draw the WaveViewImage in the GUI thread if
it is likely it can be completed in the current render pass/frame. This change
also helps reduce the flickering caused by images not being ready with threaded
rendering, but with several drawing threads, drawing in the GUI thread may not
often occur (unless explicitly requested).
Allow unfinished images to be returned from the cache in
WaveView::prepare_for_render so that new draw requests aren't queued for
duplicate images. This reduces the amount of drawing for instance in
compositions where there are many instances of the same sample/waveform
displayed on the canvas as only a single image should be drawn.
Use a random width within a certain range for
WaveView::optimal_image_width_samples so that image drawing is less likely to
occur at the same time (which will cause a spike in render/draw time and
increase the chance of flickering waveforms).
Move implementations of the private WaveView classes into wave_view_private.h
and wave_view_private.cc source files.
Incorporate a fix for limiting the waveview image size to the cairo image size
limit.
Should hopefully Resolve: #6478
Called when an item has requested a redraw and intersects with visible
canvas area.
Also add Canvas::prepare_for_render that will call Item::prepare_for_render for
items visible on the canvas.
