dummy-play-connection.hpp File Reference

Go to the source code of this file.

Description

Dummy and test setup of playback and rendering, omitting most of the Lumiera engine.

Building this dummy configuration was driven by the need to test and verify the design in the course of building the foundations of the render engine. The design of Lumiera's engine is elaborate, and thus – for a long time – we have to live with a not-yet operational engine. While, at the same time, we need to start integrating components to see if and how the design works out. So, as a remedy, we create a fixture of "coordinated placeholders". These can be used to stand-in for the real services still to be written, allowing to invoke the high-level interfaces soon. And behind the scenes, these placeholders are connected, allowing to produce specific test situations and then verify the results after the test run.

Use cases

This dummy setup can be used in various circumstances

• for unit tests we want to produce artificial test media frames: each TestFrame is produced with a reproducible pseudo-random sequence and can be verified to the last bit.
• for integration tests, we want to generate test media data, either to send them to a file, or to a real system output
• the GUI needs a dummy engine for being able to implement at least some operational pieces of functionality, instead of just creating windows, menus and icons.
• on the long run, the application will need some kind of test data generator for the users to verify a more complicated wiring setup. Thus, the DummyPlayConnection is there to stay!

Because these are somewhat similar usage scenarios, where this and that part is to be exchanged for some, we prefer a policy based design here: The DummyPlayConnection is templated to use a strategy, filling in the variable parts.

provided test services

By using different strategy template parameters, we create different flavours of the dummy; each one counting as a separate setup (not related to each other, that is). The actual instance then can just be default created; it should be placed into an scope enduring the whole usage cycle. Repeated re-initialisation or re-loading is outside the intended usage scope here.

The core interface allows to retrieve dummy implementations of

• a session model exposing exit node(s)
• generator object(s) to live within this session model
• corresponding generator nodes to serve as implementation of the former
• a low-level render node network ready to use, relying on those generator nodes
• OutputSlot implementations to serve as pseudo- or demo output facilities
• an OutputManager exposing those output facilities.

The test support interface provides a test driver for performing a controlled playback or rendering for some time. Thus, a test routine may lock into a blocking wait, to investigate results after the planned test sequence was performed.

Todo:

this was invented in 2012 – but development of the player subsystem stalled thereafter. As of 2016, I still consider this design valid and intend to pick up development when able to address this topic again. At the moment, the UI-Session connection is more urgent.

See also

lumiera::DummyPlayer

stage::PlaybackController usage example

Definition in file dummy-play-connection.hpp.

#include "steam/play/dummy-builder-context.hpp"
#include "steam/play/output-manager.hpp"
#include "lib/time/timequant.hpp"
#include "lib/iter-source.hpp"
#include "lib/nocopy.hpp"
#include "lib/util.hpp"
#include <vector>

Classes
class	DummyPlayConnection< DEF >
	Framework for dummy playback and rendering. More...
struct	PlayTestFrames_Strategy

Namespaces
	steam
	Steam-Layer implementation namespace root.
	steam::play
	Playback and rendering control subsystem.