Most of these are not errors that are intended for the user, they are only
intended for developers so don't send them to PBD::error. The errors that may
be relevant to users should be handled in libardour or the GUI in response to
return values
I put these in libpbd as that is where the debug bits are for the Waves backend
but I think it makes more sense for them to be in libardour as that is where
the AudioBackend class is defined
I left the Waves debug bits in libpbd for now.
These could also be used for return values but are initially intended for
shared translations of error messages between backends. Ideally IMO translation
should occur in the GUI(as there may be more than one) in response to these(or
similar) error codes but that would take agreement and a fair bit of
refactoring. As it is there are errors that occur in the backends that users
will want to know about this at least allows consistent translations to be
shared between backends.
copying/paste of many objects use ::set_state(, version) to set the
the state of the copy. Stateful::loading_state_version is used for
state-version in those cases.
This fails for a New Session (version==0) or when creating a New Session
after loading an Ardour2 session.
'session_frame_to_track_frame()' and its complement, 'track_frame_to_session_frame()' both accept a double and an ARDOUR::framepost_t (int64_t). For convenience these both get converted to long double. However, the functions are often called with very large values (ARDOUR::max_framepos). When this happens, rounding and precision errors can cause overflow issues. This is an attempt to alleviate that problem. Not sure if it's strictly necessary to accommodate negative values - but I'm assuming these could happen if 'speed' was negative (reverse play?)
This is the reason why 'Select All Objects' (and similar functionality) don't work for some users.
A somewhat hacky solution to address missing note-off events when a
linked midi-region is used on separate tracks at the same time.
see the source-code comment for further info.
If a "CC" automation lane was visible at least once, a Control Object
is created and henceforth saved with the session:
<Object id="automation TrackID TYPE" ../>
It is currently not possible to remove this object. (Automation > clear
will only zero all events, but not remove the Control itself.
The bug:
After showing a MIDI-CC lane at least once Events are sent for this CC.
If there is no corresponding value in the .mid, it will be zero after
session reload.
see also 7e2c8ac
Still ToDo: "Show existing automation" shows the lane even if there
are no values nor any automation at all for the given CC.
