No longer need a specialization for bool as PBD::to_string/string_to already
has specializations for bool
Remove template specialization for float as string_to/to_string handles string
representations of infinity
Add PBD::to_/string_to specializations for ARDOUR::DataType
These could go into the data_type.h header but they don't really need to and it
means that ardour/types_convert.h can just be included by source files that
need to do type<=>string conversion. A potential problem with this is that if
all the specializations are contained in a single header then any class that
requires inclusion of that header to do serialization will be recompiled each
time types_convert.h is changed. I'm not going to worry about it at this stage,
it can always be broken up or improved upon later.
A simple macro for defining the four template specializations required to
convert an enum to a string and back using the existing string_2_enum and
enum_2_string functions. Generally these will only be instantiated in one
source file, I don't think it is necessary to explicitly instantiate any at
this stage.
I would prefer "yes" and "no" as it distinguishes boolean values from numeric
but using "yes and "no" results in PBD::Property<T>::from_string failing to
parse the correct values when opening in an older Ardour version as there is no
specialization for bool.
Using 0 and 1 also results in less change to the Session file.
When the backend is dropped or changed, on engine-restart
the connection_handler() re-establishes already connected ports.
There's no disconnect when the backend dies or is hard-stopped.
In the past, we skipped processing if the routes had no inputs or outputs.
But:
A route with a generator plugin should work even if it has no inputs.
A route with "sends" should work even if it has no outputs.
(flush reverb tails etc)
PS. That comment "from RT audio thread" was wrong.
Route::flush_processors () is called from flush_all_inserts()
from Session::non_realtime_stop() which is not in rt-context.
Besides, the processor-lock regardless of the process_lock.
