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.
I'm not sure if this is really the best way to do event types (should it
just be a completely static enum in evoral, or completely dynamic and
provided by the type map, or a mix like currently?), but previously the
event type was frequently set to either total garbage, or parameter
types, which are a different thing.
This fixes all those cases, and makes Evoral::EventType an enum so the
compiler will warn about implicit conversions from int.
It is slightly questionable whether type specific methods like
velocity() belong on Event at all, these may be better off as free
functions. However the code currently uses them as methods in many
places, and it seems like a step in the right direction, since, for
example, we might some day have events that have a velocity but aren't
stored as MIDI messages (e.g. if Ardour uses an internal musical model
that is more expressive).
In any case, the former inheritance and plethora of sloppy casts is
definitely not the right thing.
PluginInsert::automation_run() subdivides plugin-run on every
control-port automation event (without splitting the process cycle).
libevoral has no automation-control context, hence this function
must be implemented by Automatable.
Add a test, based on the worked example in www.korf.co.uk/spline.pdf, for
the constrained cubic spline interpolation.
The delta values for the float comparisons are rather arbitrary, I'm sorry
to say: they're basically chosen so that everything passes.
Among other things, this means that automation controls/lists have the actual
min/max/normal/toggled of parameters, and not those inferred from the Parameter
ID, which is not correct for things like plugin parameters.
Pushing things down to the Evoral::ParmeterDescriptor may be useful in the
future to have lists do smarter things based on parameter range, but currently
I have just pushed down the above-mentioned currently used attributes.
Some of the tests for Evoral::RangeList::subtract() assume that ranges
don't contain their end (->to) point. This appears inconsistent with how
they are used elsewhere.
Add some ASCII art comments to the tests to try to clarify what they're
really testing for, and amend subtractTest1, subtractTest4, & subtractTest5
to incorporate the assumption that ranges include their end points.
Add a test function to test Evoral::coverage() with all possible overlap
types. The first test (line 161) that expects OverlapExternal will fail
with the current implementation of coverage().
There's possibly still a discussion to be had about what the overlap type of
ranges with negative lengths should be: there are currently places in the main
Ardour code base where coverage() is called with ranges where start > end.
Fix compile errors in libs/evoral/test/, by explicitly calling
Evoral::MusicalTime::to_double() wherever a double value is required of a
MusicalTime.
Some of the double variables should probably really be made into MusicalTime
ones instead, but I don't want to mess with this too much.
takeFiveTest still fails for me after this, but a failing test is probably
more informative in the long run than a test that won't even compile.
This lets us get a more explicit handle on time conversions, and is the main
step towards using actual beat:tick time and getting away from floating point
precision problems.
Make midnam test suite pass again.
The Ardour test suite does not pass. I commented out old crossfade stuff, but
I am not familiar enough with the parts that fail to fix it. It might be a
good idea for someone to look into this. Ideally we'd have the test integrated
into everyone's workflow, but they add quite a few files to compile...
git-svn-id: svn://localhost/ardour2/branches/3.0@13931 d708f5d6-7413-0410-9779-e7cbd77b26cf
they are now done with region fades, rather than separate objects.
After this commit, Ardour will try to convert your session files
to the new crossfade format, but will make a backup in your
session folder first.
If you have works in progress using Ardour 3 it is
***STRONGLY RECOMMENDED*** that you back up session files before
updating to this commit.
git-svn-id: svn://localhost/ardour2/branches/3.0@11986 d708f5d6-7413-0410-9779-e7cbd77b26cf
