diff --git a/ChangeLog b/ChangeLog index 60a1cddf..d7f15f8e 100644 --- a/ChangeLog +++ b/ChangeLog @@ -16177,3 +16177,6 @@ 2017-10-17 Fred Gleason * Moved the man pages to 'docs/manpages/'. * Stubbed out a Rivendell Operations Guide in 'docs/opsguide/'. +2017-10-17 Fred Gleason + * Added the text of the 'Generating and Maintaining Logs with + RDLogEdit' chapter to the Ops Guide. diff --git a/docs/opsguide/opsguide.xml b/docs/opsguide/opsguide.xml index 73a87587..5e54b6ae 100644 --- a/docs/opsguide/opsguide.xml +++ b/docs/opsguide/opsguide.xml @@ -1766,6 +1766,440 @@ + + Generating and Maintaining Logs with RDLogEdit + + Logs and Log Events + + A Rivendell log is a sequence of one or more events to be executed by + the system, arranged in chronological order. (This functionality is + sometimes referred to as a playlist in other automation systems). + Several different types of events can be included in a log, along + with parameters governing how and under what circumstances they will + be executed. + + + Upon startup, RDLogEdit will show the current list of all logs on the + system, as in Illustration 19. A number of important attributes of + logs can be seen from this illustration, the first being the log + name, with a summary status indicator next to it. The name is an + alpha-numeric label that is used as a unique “handle” by the system + to reference each log, and can be up to a maximum of 64 characters + long. The status indicator is intended as a quick visual guide as + to whether a particular log is ready for air (green check mark) or + not (red ex). + + + Next comes the log's description. This is a free-form alpha-numeric + label that can be used to record any information that might be useful + to have appear on the log list (e.g. “This log for Sunday's show, don't + modify!”). + + + Next comes a column showing the owning service. Each log is owned + by exactly one service, which determines under what circumstances + the log can be played and where electronic log reconciliation (ELR) + data resulting from log playouts is sent (for an overview of + Rivendell services, see section 1.1.3). + + + Next comes three “status indicator” columns ("MUSIC", + "TRAFFIC" and "TRACKS") indicating the log's + degree of readiness for air. A red indicator indicates that the + particular data element is required but currently missing, a green + indicator indicates an element is required and present, while a + white indicator indicates that an element is not required. + Additionally, the “TRACKS” column contains a pair of numbers + indicating how many completed voice tracks exist in the log versus + how many total track markers exist (the subject of voice tracks and + track markers will be covered in more detail below). When all three + of these status indicators show either green or white, the summary + status indicator (at the beginning of the log's entry in the list) + will show as a green check mark, while a red indicator in any of + these three fields will show a red ex. (NOTE: because a log sports + a red ex does not indicate that the respective log cannot be played. + It is merely a visual indicator to allow logs to be quickly + "eyeballed" for completeness). + + + Next comes a pair of columns indicating the valid start date and end + date for the log. + + + Finally, there is a column indicating the log's origin –i.e. the + place, date and time it was originally created. + + + A report that lists the available logs on the system can be generated + by touching the Log Report button. + + + A new log can be created by touching the Add button and entering a + name, or an existing log inspected and modified by touching its entry + on the log list and then touching the Edit button, resulting in the + log being opened in the Edit Log dialog as shown in Illustration 20. + The Edit Log dialog consists of three parts: the top section, where + much of the information shown on the log list can be inspected and + modified; the middle section, which shows the list of events + comprising the log, and the bottom section, where buttons for + modifying and saving the log are located. Each event in a log can + be one of several different types, indicated by the icon displayed + at the start of the line (see Table 6 for a breakdown of the various + icons). The following types of events can be incorporated into a + Rivendell log: + + + Audio Carts + + The first, and usually most common type of log event is an audio cart. + As the name implies, audio carts are Library entries that contain + audio material intended for playout. Audio carts were covered in + detail in Chapter Two in the discussion about RDLibrary. + + + + Macro Carts + + A macro cart is a cart from the Library that contains one or more + system commands that can be used to cause the system to take various + actions. They were touched upon in Chapter Two in the discussion + about RDLibrary, and will be discussed in detail in Chapter Seven. + + + + Note Markers + + A note marker is an entry in the log that contains text intended to + be seen by operators and used as a guide or reminder (program coders + sometimes refer to this sort of functionality as a remark or comment, + as seen in the REM command used by BASIC programmers). Note markers + belong to a class of log events known as meta events because (unlike + carts, which exist in the Library independently of whether they are + placed in a log or not), they have no independent existence outside + of the specific log where they are placed. A note marker has + absolutely no effect on the execution of a log other than to simply + display some text at a specified point in a log, and as such can be + useful as a mechanism for making notes or reminders to oneself or + to others who may be executing the log. + + + + Track Markers + + A track marker is another meta event that is very similar in operation + to note markers, with one key addition: track markers designate or + "bookmark" a place in the log where a voice track is to be + recorded. (The entire topic of voice tracks and tracking will be + covered in detail in Chapter Eight). As with note markers, track + markers have absolutely no effect on the execution of a log. + + + + Chain Events + + Each event in a log has a transition type, shown in the "TRANS" + column of the Edit Log dialog. The transition type determines what + happens when one event in a log ends and the next starts. Three basic + transition types can exist in a Rivendell log: PLAY, SEGUE and STOP. + + + + Import Links + + An import link is a placeholder event that shows where events imported + from the external music or traffic scheduling system will eventually + go. They will be covered in detail in the chapter on RDLogManager. + + + Each event in a Rivendell log can have its parameters modified by + touching its entry in the Edit Log dialog and then clicking the Edit + button, thus opening up the Edit Log Entry dialog, shown in + Illustration 21 for a cart event, or Illustration 22 for a meta event. + + + + + Event Transitions + + Each event in a log has a transition type, shown in the "TRANS" + column of the Edit Log dialog. The transition type determines what + happens when one event in a log ends and the next starts. Three basic + transition types can exist in a Rivendell log: PLAY, SEGUE and STOP. + + + Rivendell Log Event Type Icons + + + + + + + [AUDIO_ICON] + + + Audio Cart + + + + + [TRACK AUDIO ICON] + + + Voice Track Audio Cart + + + + + [MACRO ICON] + + + Macro Cart + + + + + [NOTE ICON] + + + Note Marker + + + + + [TRACK ICON] + + + Track Marker + + + + + [CHAINTO ICON] + + + Chain Event + + + + + [MUSICLINK ICON] + + + Music Import Link + + + + + [TRAFFICLINK ICON] + + + Traffic Import Link + + + + +
+ + The PLAY Transition + + If an event has a PLAY transition, then it will begin playing when + the previous event has finished. PLAY transitions are used when + automatic event sequencing is desired with no audio overlap (such + as when playing two voice-only announcements back-to-back). + + + + The SEGUE Transition + + SEGUE transitions are similar to PLAY transitions, with one key + difference: if the finishing event contains segue data (either from + the Library or from a custom transition programmed in the voice + tracker), then the event will start before the prior event is + finished, causing the two pieces of audio to overlap and mix together. + SEGUE transitions can be a very powerful tool for creating a variety + of special effects, particularly when used in conjunction with + musical material. + + + + The STOP Transition + + As the name implies, STOP transitions cause execution of the log to + be suspended prior to execution of the event. This is often the + desired behavior in situations where the log playout needs to be + synchronized to one or more external audio sources (such as remote + satellite feeds), and is commonly used in conjunction with Hard + Timed events (see below). + + + + + Time and Time Types + + All Rivendell log events have an associated time type, which controls + what effect (if any) the passage of time will have on the event. + There are two basic time types: relative and hard. Additionally, + the hard time type has several additional options that further modify + its behavior. + + + The Relative Time Type + + The default time type for log events, a relative time type simply + means that the event is assumed to have a start time of whenever + the previous event ends (if it has a PLAY or SEGUE transition) + or whenever it is started (if it has a STOP transition). + + + + The Hard Time Type + + A hard time type causes the event to be executed or otherwise acted + upon when the wall clock equals the time associated with the event. + Hard times are a powerful feature that can be used to synchronize + the log to various external events. An event can be assigned a + hard time by clicking the Start at check box in the Edit Log Entry + and filling in the desired time, and will show up with the letter + 'T' appearing at the beginning of its listed time in the + "TIME" column of the Edit Log dialog. An event which has + been assigned a hard time can also be set to be a Post Point by + checking the Make Post Point check box (the concept of post points + will be discussed in detail in the chapter covering RDAirPlay). + + + The specific action that is performed when the time matches is + determined by the option parameters supplied as part of the event. + Three basic actions are possible: + + + + + Start the event immediately + + + Cue to the event ("Make Next") + 1 + + Wait up to N Seconds, then start the event + + + + + Start Immediately + + As implied by the name, if the event is set to start immediately, + it will be started as soon as the hard time is reached. Any + currently playing events in the log will be stopped down. + + + + Cue to the Event ("Make Next") + + If set to 'Make Next', the event will be cued up to become the + next event to be executed in the log, bypassing any intervening + events in the log between the currently playing event and the + hard timed one. Any currently playing events are unaffected. + + + + Wait up to N Seconds, then start the event + + Very similar to "start immediately", with the + difference that, if one or more events are currently playing, + the log will wait up to the specified number of seconds + before stopping them and starting the new event. + + + + + + Editing Log Event Parameters + + Specifying a Cart + + The cart number to use for an event can be specified by touching + the Select Cart button in the Edit Log Entry dialog, which will + open up the Select Cart dialog, as shown in Illustration 23. + Alternatively, it is possible to simply enter the cart number in + the Cart field if the number is already known. The Title and + Artist information will be automatically supplied by the system + from the cart's label. + + + + Specifying Meta Event Parameters + + Note marker and track marker events each take only a single + parameter: a Comment text that will show up on the log entry. + In the case of a chain event, the name of the log to chain to must + be supplied in the Log Name field, or the Select button can be + touched to bring up the Select Log dialog to allow a name to picked + from a list of all those available. Note that meta events are + assigned transition and time types just the same as cart events. + + + + Rearranging Log EventsRearranging Log Events + + Existing events in a log can be cut, copied, pasted or rearranged + by touching the appropriate buttons in the Edit Log dialog. + In addition, touch the Delete button will cause the selected + log event(s) to be removed from the log. + + + + Saving or Abandoning Changes to a Log + + Any changes made to a log can be saved by touching either the Save + or OK buttons in the Edit Log dialog. The current log can be saved + under a different name by touching the Save As button, while + touching Cancel will abandon any changes made since the last save. + + + + Missing/Invalid Cart Events + + If a given event has a problem (such as referencing a cart that + does not exist in the Library, or that is not enabled for play on + the log's owning service) its entry will be highlighted either + RED (indicating a missing/invalid cart) or MAGENTA (indicating a + cart without permission to run on the owning service). It's also + possible to generate an exception report summarizing problem cart + entries by touching the Check Log button. + + + + + Generating Log Reports + + Various Log reports can be generated by touching the Reports button + on the Edit Log dialog and then selecting the desired report and + touching the Generate button. The following reports are available: + + + Log Listing + + A chronological listing of all events in the log. + + + + Log Exception Report + + A list of missing/unplayable carts referenced in the log. + + + + + Auditioning Audio + + The audio referenced by an audio event can be sampled in the Edit + Audio dialog by highlighting the desired event and then touching the + play button. No attempt to evaluate the rotation logic of the event + is made – the audio played is intended solely as a 'sample' to help + identify the type of material. + + +