test-driven brainstorming: define default timings...

src/proc/play/output-slot.hpp

@@ -83,6 +83,7 @@ namespace play {
   using proc::engine::BuffHandle;
   using proc::engine::BufferProvider;
   using lib::time::TimeValue;
+  using lib::time::Time;
   
   using boost::scoped_ptr;
   

src/proc/play/play-service.cpp

@@ -187,7 +187,7 @@ namespace play {
   Play::Controller
   PlayService::connect (ModelPorts dataGenerators, POutputManager outputPossibilities)
   {
-    Timings playbackTimings;       //////////////////////////////////////////////////////////////////////TICKET #875
+    Timings playbackTimings (lib::time::FrameRate::PAL);       //////////////////////////////////////////////////////TICKET #875
     
     return pTable_->establishProcess(
             PlayProcess::initiate(dataGenerators, 

src/proc/play/timings.cpp

@@ -0,0 +1,65 @@
+/*
+  Timings  -  timing specifications for a frame quantised data stream
+
+  Copyright (C)         Lumiera.org
+    2012,               Hermann Vosseler <Ichthyostega@web.de>
+
+  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 "proc/play/timings.hpp"
+#include "lib/time/formats.hpp"
+#include "lib/time/timequant.hpp"
+
+
+
+namespace proc {
+namespace play {
+  
+  
+  using lib::time::PQuant;
+  
+  namespace { // hidden local details of the service implementation....
+    
+    inline PQuant
+    buildStandardGridForFramerate (FrameRate fps)
+    {
+      return PQuant (new lib::time::FixedFrameQuantiser (fps));
+    }                         //////TODO maybe caching these quantisers? they are immutable and threadsafe
+    
+    
+  } // (End) hidden service impl details
+  
+  
+  /** Create a default initialised Timing constraint record.
+   * Using the standard optimistic settings for most values,
+   * no latency, no special requirements. The frame grid is
+   * rooted at the "natural" time origin; it is not related
+   * in any way to the current session.
+   * @remarks this ctor is intended rather for testing purposes!
+   *          Usually, when creating a play/render process,
+   *          the actual timings \em are related to the timeline
+   *          and the latency/speed requirements of the output.
+   */
+  Timings::Timings (FrameRate fps)
+    : grid_(buildStandardGridForFramerate(fps))
+    , playbackUrgency (ASAP)
+    { }
+
+  
+
+}} // namespace proc::play

src/proc/play/timings.hpp

@@ -53,20 +53,30 @@
 //#include <boost/noncopyable.hpp>
 //#include <string>
 //#include <vector>
-//#include <tr1/memory>
+#include <tr1/memory>
 //#include <boost/scoped_ptr.hpp>
 
+namespace lib {
+namespace time{
+  class Quantiser;
+}}
 
 namespace proc {
 namespace play {
 
-  using lib::time::Time;
+  using lib::time::FrameRate;
+  using lib::time::TimeValue;
 //using std::string;
 
 //using std::vector;
 //using std::tr1::shared_ptr;
 //using boost::scoped_ptr;
   
+  enum PlaybackUrgency {
+    ASAP,
+    NICE,
+    TIMEBOUND
+  };
   
   
   
@@ -80,7 +90,21 @@ namespace play {
    */
   class Timings
     {
+      typedef std::tr1::shared_ptr<const lib::time::Quantiser> PQuant;
+      
+      PQuant grid_;
+      
     public:
+      PlaybackUrgency playbackUrgency;
+      
+      Timings (FrameRate fps);
+      
+      // default copy acceptable
+      
+      TimeValue getOrigin();
+      
+      FrameRate getFrameRate();
+      
       
       //////////////TODO further accessor functions here
       

tests/components/proc/engine/engine-interface-test.cpp

@@ -31,6 +31,7 @@
 #include "proc/play/diagnostic-output-slot.hpp"
 #include "proc/mobject/model-port.hpp"
 #include "proc/asset/pipe.hpp"
+#include "lib/time/timevalue.hpp"
 
 //#include <boost/scoped_ptr.hpp>
 //#include <iostream>
@@ -50,6 +51,7 @@ namespace test  {
   using mobject::ModelPort;
   using proc::play::OutputSlot;
   using proc::play::DiagnosticOutputSlot;
+  using lib::time::FrameRate;
   
   typedef asset::ID<Pipe> PID;
   typedef OutputSlot::Allocation Allocation;
@@ -94,7 +96,7 @@ namespace test  {
           
           OutputSlot& oSlot = DiagnosticOutputSlot::build();
           Allocation& output = oSlot.allocate();
-          Timings timings; /////////TODO
+          Timings timings (FrameRate::PAL); /////////TODO
           
           // Invoke test subject...
           CalcStreams calc = engine.calculate(port, timings, output);

tests/components/proc/play/timing-constraints-test.cpp

@@ -24,6 +24,7 @@
 #include "lib/test/run.hpp"
 
 #include "proc/play/timings.hpp"
+#include "lib/time/timevalue.hpp"
 //#include "proc/engine/buffhandle.hpp"
 //#include "proc/engine/testframe.hpp"
 //#include "lib/time/control.hpp"
@@ -34,8 +35,9 @@ namespace proc {
 namespace play {
 namespace test {
   
-  namespace time = lib::time;
-  
+  using lib::time::Time;
+  using lib::time::FrameRate;
+
 //using proc::engine::BuffHandle;
 //using proc::engine::test::testData;
 //using proc::engine::test::TestFrame;
@@ -63,7 +65,12 @@ namespace test {
       void
       define_basicTimingConstraints()
         {
+          Timings timings (FrameRate::PAL);
+          
 #if false /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #831
+          CHECK (Time::ZERO == timings.getOrigin());
+          CHECK (FrameRate::PAL == timings.getFrameRate());
+          CHECK (ASAP == timings.playbackUrgency);
 #endif    /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #831
         }
     };

tests/lib/time/time-quantisation-test.cpp

@@ -154,7 +154,7 @@ namespace test{
       checkGridBinding (TimeValue org)
         {
           // refer to a grid not yet defined
-          VERIFY_ERROR (UNKNOWN_GRID, QuTime wired(org, "special_funny_grid"));
+          VERIFY_ERROR (UNKNOWN_GRID, QuTime weird(org, "special_funny_grid"));
           
           TimeGrid::build("special_funny_grid", 1);      // provide the grid's definition (1 frame per second)
           

wiki/renderengine.html

@@ -7468,7 +7468,7 @@ Actually, what the GUI creates and uses is the //view// of a given timeline. Thi
 To complement this possibilities, I'd propose to give the //timeline view// the possibility to be re-linked to a sub-sequence. This way, it would stay connected to the main play control, but at the same time show a sub-sequence //in the way it will be treated as  embedded// within the top-level sequence. This would be the default operation mode when a meta-clip is opened (and showed in a separate tab with such a linked timeline view). The reason for this proposed handling is again to give the user the least surprising behaviour. Because, when — on the contrary — the sub-sequence would be opened as //separate timeline,// a different absolute time position and a different signal routing may result; doing such should be reserved for advanced use, e.g. when multiple editors cooperate on a single project and a sequence has to be prepared in isolation prior to being integrated in the global sequence (featuring the whole movie).
 </pre>
 </div>
-<div title="Timings" modifier="Ichthyostega" created="201202042240" tags="spec draft Rendering Player" changecount="1">
+<div title="Timings" modifier="Ichthyostega" modified="201202060103" created="201202042240" tags="spec draft Rendering Player" changecount="2">
 <pre>//Timing constraints of a render or playback process.//
 
 !design quest {{red{WIP 1/2012}}}
@@ -7480,7 +7480,9 @@ The Timings record is used at various places at the engine interface level. Up t
 * besides, it's clear that the Timings record is consulted to find out about latency
 * question: do we need a relation to wall-clock time?
 
-</pre>
+!where are the timings definied?
+Timing constraint records are used at various places within the engine. Basically we need such a timings record for starting any kind of playback or render.
+The effective timings are established when //allocating an OutputSlot// -- based on the timings defined for the ModelPort  to //perform,// i.e. the global bus to render.</pre>
 </div>
 <div title="Track" modifier="Ichthyostega" modified="200911202133" created="200801062320" tags="def design decision" changecount="6">
 <pre>Tracks are just a structure used to organize the Media Objects within the Sequence. Tracks are associated allways to a specific Sequence and the Tracks of an Sequence form a //tree.// They can be considered to be an organizing grid, and besides that, they have no special meaning. They are grouping devices, not first-class entities. A track doesn't &quot;have&quot; a port or pipe or &quot;is&quot; a video track and the like; it can be configured to behave in such manner by using placements.