Document the /dev/null special case.

[nageru-docs] / futatabi.rst

diff --git a/futatabi.rst b/futatabi.rst
index 76ee84149f64453784dd06528fbdbd8f38f64989..171f861f25c59853dde675b30106d21fbe7f7a88 100644 (file)
--- a/futatabi.rst
+++ b/futatabi.rst
@@ -34,7 +34,7 @@ System requirements
 
 It is strongly recommended to run Futatabi on a separate machine from Nageru,
 not the least because you probably want a different person to operate the replay
-while the producer is operating Nageru.
+while the producer is operating Nageru. (See :ref:`coop`.)
 
 Like Nageru, Futatabi uses your GPU for nearly all image processing.
 However, unlike Nageru, Futatabi requires a powerful GPU for interpolation;
@@ -74,7 +74,11 @@ directory (you can change it with the -d option). This holds all of the
 recorded frames, all metadata about clips, and preferences set from the menus
 (interpolation quality and cue point padding).  If you quit Futatabi and
 restart it (or you go down as the result of a power failure or the likes),
-it will remember all the state and frames for you.
+it will remember all the state and frames for you. As a special case,
+if you give */dev/null* in place of an input URL or file, you can keep using
+your workspace without getting any new frames added.
+
+.. _basicui:
 
 Basic UI operations
 '''''''''''''''''''
@@ -111,8 +115,33 @@ to cut to your channel, click on the first clip you want to play back and
 click the “Play” button (space on the keyboard); the result will both be
 visible in the top screen and go out live over the network to Nageru.
 
-On top of these basics, there are many possible workflows; we'll discuss only
-two. Try out a few and see which ones fit your style and type of event.
+.. _coop:
+
+Working with your producer
+''''''''''''''''''''''''''
+
+Generally, we recommend that the producer (Nageru operator) and slow motion
+operator (Futatabi operator) sit closely together and can communicate verbally.
+Good cooperation between the two is essential to get a good final product;
+especially the switches to and from the replays can be a critical point.
+
+The general rule for working together is fairly obvious: The producer should
+switch to a replay when there's something to show, and switch away when there's
+nothing more to show (or, less ideally, when something live takes priority).
+Generally, when you have a playlist ready, inform your producer; they will
+count you in (three, two, one, go). At one, start playing so that you have some
+margin. If the Nageru theme is set up correctly (see :ref:`talkback`), they will
+know how much is queued up so that they can switch back before the replay runs
+out, but it doesn't hurt to give a warning up-front. The producer might also
+be able to request replays of specific events, or ask you to save something
+for later if they can't show it right now (e.g. a foul situation that wasn't called).
+
+Replay workflows
+----------------
+
+On top of the basics outlined in :ref:`basicui`, there are many possible
+workflows; we'll discuss only two. Try out a few and see which ones fit your
+style and type of event.
 
 Repeated cue-in
 '''''''''''''''