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).
Changing the track-type to add changes the name which marked the
name-entry as "edited by user", even though it was Ardour itself
which changed the name.
