endless loop: e.g. 2in2out -> balance (or 1in1out)
#23 0xb7ab5c17 in ARDOUR::Pannable::value_as_string
#24 0xb2ebb206 in ARDOUR::Pannerbalance::value_as_string
#25 0xb7ab5c17 in ARDOUR::Pannable::value_as_string
#26 0xb2ebb206 in ARDOUR::Pannerbalance::value_as_string
ad infinitum
This allows to move from stereo,mono panners to VBAP and back
and also facilitates sharing pannables of all currently
existing panners with semantically similar results.
(somewhat dirty solution, this retains PBD::spherical_to_cartesian
and maps angles pretty much everywhere else)
* connect 2D panner "edit" to big window
* disconnect 2D-panner GUI when it's visible but panner-type changes
* ignore mixer-strip level-meter context-menu for Aux-sends
Add a ReaderLock to Route::process_output_buffers().
But process_output_buffers() is always called with processor-lock
held. To avoid deadlocks, a processor WriterLock must always imply
a process-lock (IFF reconfigure-I/O is called with _processor_lock).
Otherwise: e.g.
* add_processor() -> takes processor-lock. set up and activate processor.
* simult. audio-engine process, process-lock -> call process_output_buffers() -> wait for processor-lock
* add_processor() continues -> calls reconfigure-io -> take process-lock -> deadlock.
fixes possible crash if a processor modifies port-count
1. a processor is inserted and activated with processor-lock held
2. only after that the process_lock() is taken, configure_processors() is called which reconfigures-IO
BUT if the processor that is inserted changes the channel count AND audio is processed before IOs are reconfigured
-> possible crash (invalid port-buffers)
To reproduce: Bus1 (2in, 3out), Bus2 (2in, 3out)
- add a send from Bus1 to Bus2,
- then add a processor to Bus1, just before the send which
increases the channel-count to 4 -> occasional crash or assert.
