This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
It can happen that with a scaling factor of 1.0, rubberband
produces slightly fewer samples than the original.
Region::set_length (region->length * 1.0) is idempotent and
does not shorten it as appropriate to the longest source
via Region::verify_length(), which leads to various issues.
For some reason applying the property change
plist.add (Properties::start, std::numeric_limits<timepos_t>::min());
does not correctly reset the offset of the newly created region.
It is an offset from an *implicit* origin (the source zero), not from an explicit origin,
and this fits with the concept underlying timepos_t. A timecnt_t requires an explicit origin,
which makes no sense in this context (just as it doesn't for the timeline as a whole).
Completing readout available() returns 0, until all
background threads have finished and joined.
This also improves performance by feeding suggested/required
amount of samples on every process() call.
This is relevant when time-stretch is canceled. In that case
stretcher.process() is never called with final=true, and hence
stretcher.available() will always return a value >=0.
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
- for those not in the know, this series provides a way to
remove the temporal distortion introduced when using an
audio frame-based gui for music-locked objects.
In short, the gui uses an audio frame representation to move
objects. It displays the object using frame_at_beat(), quantizing
the time value to audio frames. This is fine until the user selects
that frame but expects it to be interpreted as a beat.
Thus beat_at_frame() would not produce the user-expected beat
(temporal quantization error of up to 0.5 audio samples).
This is one method of mapping audio time to music time accurately.
It's slightly possible that this causes trivial build failures on different
configurations, but otherwise shouldn't cause any problems (i.e. no actual
changes other than include/naming/namespace stuff). I deliberately avoided
removing libardour-config.h since this can mysteriously break things, though a
few of those do seem to be unnecessary.
This commit only targets includes of ardour/*.h. There is also a very large
number of unnecessary includes of stuff in gtk2_ardour; tackling that should
also give a big improvement in build time when things are modified.
git-svn-id: svn://localhost/ardour2/branches/3.0@12420 d708f5d6-7413-0410-9779-e7cbd77b26cf
Vimmers, try let c_space_errors = 1 in your .vimrc to highlight this kind of stuff in red. I don't know the emacs equivalent...
git-svn-id: svn://localhost/ardour2/branches/3.0@5773 d708f5d6-7413-0410-9779-e7cbd77b26cf
All #include statements that include a header that is a part of a library
bundled with ardour MUST use quotes, not angle brackets.
Do this:
#include "ardour/types.h"
NOT this:
#include <ardour/types.h>
Rationale:
This is best practice in general, to ensure we include the local version
and not the system version. That quotes mean "local" (in some sense)
and angle brackets mean "system" (in some sense) is a ubiquitous
convention and IIRC right in the C spec somewhere.
More pragmatically, this is required by (my) waf (stuff) for dependencies
to work correctly. That is:
!!! FAILURE TO DO THIS CAN RESULT IN BROKEN BUILDS !!!
Failure to comply is punishable by death by torture. :)
P.S. It's not that dramatic in all cases, but this (in combination with some
GCC flags specific to the include type) is the best way I have found to be
absolutely 100% positive the local ones are being used (and we definitely
want to be absolutely 100% positive on that one).
git-svn-id: svn://localhost/ardour2/branches/3.0@4655 d708f5d6-7413-0410-9779-e7cbd77b26cf