Lumiera
0.pre.03
»edit your freedom«
|
Go to the source code of this file.
Modifying time and timecode values.
Basically, time values are designed to be immutable. Under some circumstances we need a means to change existing time values though. Moreover, actually performing these changes gets quite involved at the implementation level, due to time / timecode values being quantised (grid aligned). To keep this implementation logic separate from the simple time values, and to allow for later extensions and more elaborate change schemes, we choose the visitor pattern for implementing these time mutating operations.
There are four basic usage situations causing an existing time value to be mutated:
All these include sending a change message to the original time spec, while the actual content of the change message determines the concrete behaviour. Especially, when the target time to be changed or the message content are quantised, an interference between multiple time grids may be happen, possibly resulting in a re-quantisation of the message into the target object's own time grid.
timequant.hpp
needs to be included prior to mutation.hpp
Obviously, you can't define any mutation involving quantised (grid aligned) values without this. Definition in file mutation.hpp.
#include "lib/error.hpp"
#include "lib/nocopy.hpp"
#include "lib/time/timevalue.hpp"
#include "lib/polymorphic-value.hpp"
#include "lib/symbol.hpp"
Classes | |
class | Mutation |
Interface: an opaque change imposed onto some time value. More... | |
Typedefs | |
typedef lib::polyvalue::CloneValueSupport< Mutation > | ClonableMutation |
typedef lib::PolymorphicValue< Mutation, MUTATION_IMPL_SIZE, ClonableMutation > | EncapsulatedMutation |
Enumerations | |
enum | { MUTATION_IMPL_SIZE = sizeof(TimeValue) } |
Functions | |
LUMIERA_ERROR_DECLARE (INVALID_MUTATION) | |
Changing a time value in this way was not designated. | |
Namespaces | |
lib | |
Implementation namespace for support and library code. | |