DiskWriter is a processor and as such has no Input object. This means
that the "Automatic" setting must be handled by the Track, which
does have an Input object to check for port connections to physical
or non-physical sources
* Emit signal once midnam was actually updated
* only re-read midnam if was it changed. This allows idempotent calls to
read_midnam() - from the same thread.
At session-load a synth-plugin may load a soundfont in the background
and emit midnam_update() after the synth was initialized but before the
GUI thread connects to the signal. By making the call idempotent the
GUI can call read_midnam() after connecting to the signal to catch up.
When forking regions, copying playlists or saving snapshots we do not
have a reference to the track and cannot use the track's name as basis
for the new filename like Editor::fork_region() does.
A cloned midi region's name is based on the original region name.
This prevents endless addition "name-1-1-1-1-1-1-1-1.mid", adding
to the region's basename.
The queued resize will only happen trigger a size-request when the
widget is realized, and on_size_request() calls ensure_layout().
Moreover, this over protection meant that sometimes a resize wasn't
noticed by the button containers.
pthread-w32 does not support pthread_setschedparam() with
SCHED_FIFO and bails out. While pthread_create() simply ignores the policy
and sets the priority regadless.
This only affects ctrl-surface event-loops & AutomationWatch on Windows.
IO used to manually keep a list of user bundles it was connected to, but
it didn't work correctly: sometimes it didn't notice that a bundle
wasn't connected anymore, and the list wasn't correctly persisted across
save/reloads among other things.
Moreover, it wasn't needed at all, since the user bundles are correctly
listed by _session.bundles() and IO already notices they are connected !
Remove all occurrences of |_bundles_connected| and |check_bundles_connected|.
When |allow_partial| is true, only when the number of channels of a
given DataType is the same for both bundles are the corresponding
channels connected together.
When |allow_partial| is false (the default), the number of channels must
match for each DataType (the ChanCounts must be equal) for the
connection to be attempted.
This also fixes the logic in case two bundles have the same number of
channels, or even the same ChanCounts, but not with the DataTypes in the
same order (so connecting the ith channel of the bundle to the ith
channel of the other bundle makes no sense).
|Bundle::nchannels()| creates a ChanCount on demand, by iterating over
the |_channel| member variable. The sum of all |nchannels().n(t)| over
all non-NIL DataTypes |t| is thus equal to |_channel.size()|.
Consequently, calling |nchannels().n_total()| is a convoluted (and slow)
way of getting |_channel.size()|. Add a method |Bundle::n_total()| that
directly returns the latter.
When starting ardour using the jack backend, playback only devices
currently do not get displayed. Mixing and Mastering only workspaces
with e.g. a single USB Dac should be a common use case. Take this use
case into account by adding them to the device list. Tested on Linux
with jack-alsa.
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.
