back to business: now able to implement time mutation messages

src/lib/time/mutation.cpp

@@ -65,8 +65,8 @@ namespace time {
    * concrete time value mutation:
    * impose fixed new start time.
    */
-  class SetNewStartTime
-    : public Mutation
+  class SetNewStartTimeMutation
+    : public ClonableMutation
     {
       TimeValue newTime_;
       
@@ -96,29 +96,81 @@ namespace time {
       
     public:
       explicit
-      SetNewStartTime (TimeValue t)
+      SetNewStartTimeMutation (TimeValue t)
         : newTime_(t)
         { }
     };
   
   
+  /** 
+   * concrete time value mutation:
+   * impose fixed new start time.
+   */
+  class SetNewDuration
+    : public ClonableMutation
+    {
+      Duration changedDuration_;
+      
+      virtual void
+      change (Duration& target)  const
+        {
+          imposeChange (target, changedDuration_);
+        }
+      
+      
+      virtual void
+      change (TimeSpan& target)  const
+        {
+          imposeChange (target.duration(), changedDuration_);
+        }
+      
+      
+      /** @note the re-quantisation happens automatically
+       *  when the (changed) QuTime is materialised */
+      virtual void
+      change (QuTime&)    const
+        {
+          throw error::Logic ("mutating the duration of a (quantised) time point doesn't make sense"
+                             , LUMIERA_ERROR_INVALID_MUTATION);
+        }
+      
+      
+    public:
+      explicit
+      SetNewDuration (Duration dur)
+        : changedDuration_(dur)
+        { }
+    };
   
-  /** */
-  void
+  
+  
+  /** Convenience factory to yield a simple Mutation changing the absolute start time.
+   *  This whole procedure might look quite inefficient, but actually most of the
+   *  abstractions are removed at runtime, leaving only a single indirection 
+   *  through the VTable of the Mutation Interface.
+   * @throw  error::Logic when attempting to change the (non existent) start time of a Duration
+   * @return EncapsulatedMutation, which is an "polymorphic value object",
+   *         actually carrying an embedded Mutation subclass with the new start time
+   */
+  EncapsulatedMutation
   Mutation::changeTime (Time newStartTime)
   {
-    UNIMPLEMENTED ("perform a trivial mutation to set a new fixed time value");
+    return EncapsulatedMutation::build<SetNewStartTimeMutation> (newStartTime);
   }
   
   
-  void
-  Mutation::changeDuration (Duration)
+  /** Convenience factory: simple Mutation to adjust the duration or length of a timespan
+   * @throw error::Logic when attempting to change the "duration" of a quantised time point
+   * @return EncapsulatedMutation, carrying the new duration value to impose
+   */
+  EncapsulatedMutation
+  Mutation::changeDuration (Duration changedDur)
   {
-    UNIMPLEMENTED ("perform a trivial mutation to set a new Duration");
+    return EncapsulatedMutation::build<SetNewDuration> (changedDur);
   }
   
   
-  void
+  EncapsulatedMutation
   Mutation::nudge (int adjustment)
   {
     UNIMPLEMENTED ("Nudge by a predefined nudge amount");

src/lib/time/mutation.hpp

@@ -55,6 +55,7 @@
 
 #include "lib/error.hpp"
 #include "lib/time/timevalue.hpp"
+#include "lib/polymorphic-value.hpp"
 //#include "lib/symbol.hpp"
 
 #include <boost/noncopyable.hpp>
@@ -72,6 +73,18 @@ namespace time {
   LUMIERA_ERROR_DECLARE (INVALID_MUTATION); ///< Changing a time value in this way was not designated
   
   class QuTime;
+  class Mutation;
+  
+  
+  /* The following typedefs allow to hand out
+   * "unspecific" mutation value objects from 
+   * factory functions, without disclosing any
+   * implementation details here in this header.
+   */
+  enum{ MUTATION_IMPL_SIZE = sizeof(TimeValue) };
+  
+  typedef lib::polyvalue::CloneValueSupport<Mutation> ClonableMutation;
+  typedef lib::PolymorphicValue<Mutation, MUTATION_IMPL_SIZE, ClonableMutation> EncapsulatedMutation;
   
   /**
    * Interface: an opaque change imposed onto some time value.
@@ -80,7 +93,6 @@ namespace time {
    * @todo WIP-WIP-WIP
    */
   class Mutation
-    : boost::noncopyable
     {
     public:
       virtual ~Mutation();
@@ -91,9 +103,9 @@ namespace time {
       
       /* === convenience shortcuts for simple cases === */
       
-      static void changeTime (Time);
-      static void changeDuration (Duration);
-      static void nudge (int adjustment);
+      static EncapsulatedMutation changeTime (Time);
+      static EncapsulatedMutation changeDuration (Duration);
+      static EncapsulatedMutation nudge (int adjustment);
       
     protected:
       static void imposeChange (TimeValue&, TimeValue);

src/lib/time/timevalue.hpp

@@ -380,6 +380,12 @@ namespace time {
         { }
       
       
+      Duration&
+      duration() 
+        {
+          return dur_;
+        }
+      
       Duration
       duration()  const 
         {

src/proc/asset.hpp

@@ -130,7 +130,7 @@ namespace asset {
    * - asset::Media representing mediafiles
    * - asset::Proc representing media data processing components (e.g. Effects)
    * - asset::Struct representing structural components used in the session (e.g. Tracks)
-   * - asset::Meta representing meta objects created while editing (e.g. Automation)
+   * - asset::Meta representing metadata, parametrisation, customisation.
    *  
    * And of course there are various concrete Asset subclasses, like asset::Clip,
    * asset::Effect, asset::Codec, asset::Track, asset::Dataset.

wiki/renderengine.html

@@ -6618,7 +6618,7 @@ 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]]
 </pre>
 </div>
-<div title="TimeMutation" modifier="Ichthyostega" modified="201104040005" created="201101231344" tags="spec discuss draft" changecount="31">
+<div title="TimeMutation" modifier="Ichthyostega" modified="201104250335" created="201101231344" tags="spec discuss draft" changecount="34">
 <pre>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
@@ -6666,9 +6666,10 @@ This results in the following combinations to be implemented:
 |~|quantised ||set raw value |
 | Duration|~TimeSpan ||set length |
 |~|Duration  ||set length |
+|~|quantised || -- |
 | Offset|Time || -- |
-|~|Duration || -- |
-|~|~TimeSpan ||adjust start/length |
+|~|Duration ||adjust length |
+|~|~TimeSpan ||adjust start |
 |~|quantised ||adjust raw value |
 | ~QuTime|any raw ||treat as raw ~TimeValue |
 |~|~QuTime ||materialise, then set raw |
@@ -6698,8 +6699,7 @@ Question is: how fine grained and configurable needs this to be?
 !!! design draft
 The special focus of this problem seems to lead itself to a __visitor pattern__ based implementation. Because the basic hierarchy of applicable types is fixed, but the behaviour is open ended (and not yet fully determined). A conventional implementation would scatter this behaviour over all the time entities, thus making it hard to understand and reason about. The classical ~GoF cyclic visitor solution to the contrary allows us to arrange closely related behaviour into thematically grouped visitor classes. As a plus, the concrete action can be bound dynamically, allowing for more flexibility when it comes to dealing with the intricate situations when a quantised time span (= a clip) recieves a quantised mutation (= is re-alligend to a possibly different frame grid)
 
-Thus the possibly mutalble time entities get an {{{accept(time::Mutation)}}} function, which is defined to reflect back into the (virtual) visitation functions of the Mutation Interface. Additionally, we provide some static convenience shortcuts right in the
-Mutation interface, performing the trivial mutations.
+Thus the possibly mutalble time entities get an {{{accept(time::Mutation&amp;)}}} function, which is defined to reflect back into the (virtual) visitation functions of the Mutation Interface. Additionally, we provide some static convenience shortcuts right in the Mutation interface, performing the trivial mutations.
 </pre>
 </div>
 <div title="TimeQuant" modifier="Ichthyostega" modified="201101232031" created="201012181753" tags="Concepts Player spec img discuss draft" changecount="50">