From ab72b528c8c7b0e3a92155010e2136e61aabd59c Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Mon, 7 Mar 2011 02:52:47 +0100 Subject: [PATCH] draft test for changing time specs --- tests/40components.tests | 5 + tests/lib/time/time-mutation-test.cpp | 127 ++++++++++++++++++++++++++ wiki/renderengine.html | 11 ++- 3 files changed, 139 insertions(+), 4 deletions(-) create mode 100644 tests/lib/time/time-mutation-test.cpp diff --git a/tests/40components.tests b/tests/40components.tests index 98e5c290a..7b3bdd31d 100644 --- a/tests/40components.tests +++ b/tests/40components.tests @@ -678,6 +678,11 @@ return: 0 END +TEST "Changing time specifications" TimeMutation_test < + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of + the License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +* *****************************************************/ + + +#include "lib/test/run.hpp" +#include "lib/test/test-helper.hpp" +#include "lib/time/timevalue.hpp" +#include "lib/time/timequant.hpp" +//#include "lib/time/display.hpp" +#include "lib/util.hpp" + +#include +#include +//#include +#include + +using boost::lexical_cast; +using util::isnil; +//using std::rand; +using std::cout; +using std::endl; +using std::string; + +//using lumiera::error::LUMIERA_ERROR_BOTTOM_VALUE; + +namespace lib { +namespace time{ +namespace test{ + + namespace { + inline string + pop (Arg arg) + { + if (isnil (arg)) return ""; + string entry = arg[0]; + arg.erase (arg.begin()); + return entry; + } + } + + + /**************************************************************** + * @test cover all basic cases for mutating a time specification. + * - change to a given value + * - change by an offset + * - change using a grid value + * - apply an (grid) increment + */ + class TimeMutation_test : public Test + { + gavl_time_t + random_or_get (string arg) + { + if (isnil(arg)) + return 1 + (rand() % 10000); + else + return lexical_cast (arg); + } + + + virtual void + run (Arg arg) + { + TimeValue o (random_or_get (pop(arg))); + TimeValue c (random_or_get (pop(arg))); + + PQuant fixQ (new FixedFrameQuantiser(FrameRate::PAL)); + QuTime qVal (o, fixQ); + FrameNr count(qVal); + + mutate_by_Value (o, c); + mutate_by_Offset (o, Offset(c)); + mutate_quantised (o, qVal); + mutate_by_Increment(o, count); + } + + + void + mutate_by_Value(TimeValue o, TimeValue change) + { + } + + + void + mutate_by_Offset (TimeValue o, Offset change) + { + } + + + void + mutate_quantised (TimeValue o, QuTime change) + { + } + + + void + mutate_by_Increment (TimeValue o, int change) + { + } + }; + + + /** Register this test class... */ + LAUNCHER (TimeMutation_test, "unit common"); + + + +}}} // namespace lib::time::test diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 1985b9c83..96acf0937 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -6618,8 +6618,8 @@ Thus no server and no network connection is needed. Simply open the file in your * see [[Homepage|http://tiddlywiki.com]], [[Wiki-Markup|http://tiddlywiki.org/wiki/TiddlyWiki_Markup]] -
-
Simple time points are just like values and thus easy to change. The difficulties arise when time values are to be //quantised to an existing time grid.// The first noticeable point to note is that now the effect can be decoupled from the cause. Small changes below the threshold might be accumulated, and a tiny change might trigger a jump to the next grid point. While this might be annoying, the yet more complex questions arise when we acknowledge that the change itself might be related to a time grid.
+

+
Simple time points are just like values and thus easy to change. The difficulties arise when time values are to be //quantised to an existing time grid.// The first relevant point to note is that for quantised time values, the effect of a change can be disproportional to the cause. Small changes below the threshold might be accumulated, and a tiny change might trigger a jump to the next grid point. While this might be annoying, the yet more complex questions arise when we acknowledge that the amount of the change itself might be related to a time grid.
 
 The problem with modification of quantised values highlights an inner contradiction or conflicting goals within the design
 * the whole system should fit in naturally and just feel like using raw time values
@@ -6631,7 +6631,7 @@ At this point, we should recall some general assumptions within Lumiera
 * there are no hard-coded defaults regarding the specific nature of the manipulated objects (format, number of channels)
 * there is not "the" timeline, but we have multiple timelines
 * sequences might be nesetd and thus be brought into a different context
-* framerate is a property of the stream type of a channel; it depends on the output. Ther is no global format or framerate.
+* framerate is a property of the stream type of a channel; it depends on the output. There is no global format or framerate.
 
 !Usage situations
 The complexity arises from the mixture of several concerns, which often blend into a single usage situation.
@@ -6680,7 +6680,10 @@ As rationale, consider the following
 * time values are immutable (as far as possible)
 * only allow to assign a completely new setting
 * only accept raw time values for redefining a quantised interval
-* only accept an abstract //modification object.//
+* only accept an abstract //modification object.// &rarr;{{red{No! any kind of abstraction requires an indirection}}}
+
+{{red{Question 3/11}}} -- can we avoid accepting mutations for Time (and thus only mutate ~TimeSpan)?
+Rationale: allowing mutations for Time bears the danger of making ~TimeVar obsolete
 
 !!!usage considerations
 Question is: how fine grained and configurable needs this to be?