Rivendell includes two modules specially optimized for performing automatic operations: the RDCatch and RDAirPlay modules. However, these two modules take radically different approaches in how they go about organizing and controlling operations, so a few words regarding each may be in order here. RDCatch is aimed at executing actions on the basis of a strict time-based schedule, referred to as an event list. Each action (which can be a recording, a play out, an upload or download, a macro execution or an operation on an audio switcher device) executes on the basis of its scheduled time in the event list, independently of all other actions. As such, RDCatch is often best suited for use in settings such as network head end operations or 'auxiliary' roles at broadcast stations, where the transitions between events are generally not an important part of the presentation. RDAirPlay takes a very different approach, in that most events are organized into one or more playlists or logs. A Rivendell log is a list of one or more carts, organized in chronological order. As the name implies, RDAirPlay is optimized for use in situations where the transitions between the various program elements are a key part of the delivery and presentation of the content, such as in live air play environments. Of course, it's entirely possible to use both modules, even together on the same machine at the same time – the Linux OS makes for a very robust and capable multitasking system. In this chapter, we will take a look at the capabilities of RDCatch. After starting up RDCatch, you will see the . The window consists of four areas: the record / play out decks at the top, the filter areas just below the decks, the events list and the audition buttons and other buttons at the bottom. We'll cover each of these in turn. If the system administrator has configured one or more RDCatch record or play out decks, they will be visible at the top of the RDCatch main window. A record deck is a virtual 'recorder' that can be used to make automated recordings, while a play out deck can be used to automatically play out audio. It does not matter on which particular host a particular deck resides – all Rivendell decks throughout the system are visible in RDCatch, regardless of which host it is run upon. Starting at the left-hand edge of each deck, there is the deck's name, consisting of the name of the deck's host machine followed by a number and a letter, an R to indicate a record deck and a P to indicate a play out deck. Next, for record decks, there is a MON button, used to monitor the audio present at the deck input, followed by an ABORT button, used to manually stop an event running in the deck. A description of the currently running event next appears (this area will be blank if no event is currently active), followed by the deck's status, which could be any of the values in . Status Meaning IDLE The deck is available for events READY The deck has started monitoring audio but the transport is not yet rolling (record decks only). WAITING The deck is waiting for a GPI event (record decks only) RECORDING The deck is recording (record decks only) PLAYING The deck is playing out (play out decks only) OFFLINE The deck is configured but not available The RDCatch Main Window Finally, each deck has an audio meter on its right-hand end, used to verify audio levels in realtime. Immediately below the decks is the filter area, consisting of the Show Only Active Events, Show Only Today's Events Show DayOfWeek and Show Event Type controls, which are used to select which events will be visible in the events list area immediately below. The event list is a system wide list of all events to be executed by RDCatch on all of the various hosts on the Rivendell network, with each event occupying a single line. The status of each event is indicated by its background color, as shown in Color Meaning YELLOW The event is next to be executed. GREEN The event is active. CYAN The event is in the READY state. VIOLET The event is in the WAITING state. RED/PINK The event is reporting an error. Each entry in the event list starts with an icon that indicates the type of the event, as shown in [RECORD_ICON] Record Event [PLAYOUT ICON] Play Out Event [SWITCH ICON] Switch Event [MACRO ICON] Macro Event [UPLOAD ICON] Upload Event [DOWNLOAD ICON] Download Event Next on each line comes the Description (settable by the user) and Location for the event, the location being the name of the host/deck where the event will run. Then comes the Start and End parameters. These time-based parameters come in one of three different forms: a hard time, which is simply an absolute time (in twenty-four hour 'military' format), a length (in HH:MM format, relative to an earlier start time), or a GPI start. The GPI parameters can be somewhat involved. They are specified in the following format: Gpi: <start-time>,<end-time>,<gpi-num>,<wait-time> Where: <start-time> The time, in HH:MM:SS format, when RDCatch will start looking for a GPI event (also sometimes referred to as the window start time). <end-time> The time, in HH:MM:SS format, when RDCatch will stop looking for a GPI event (also sometime referred to as the window end time). <gpi-num> The number of the GPI event to wait for, in the format MATRIX:LINE. We will deal with GPI matrix and line numbers in detail when we cover RDAdmin. <wait-time> The amount of time to wait, in MM:SS format, between the reception of the GPI event and the actual start of the event (used only for Start parameters). For example, the start parameter 'Gpi: 14:00:00,14:05:59,0:1,01:00' has a window start time of 14:00:00 [2:00:00 PM], a window end time of 14:05:59, looks for a GPI event on line 0:1 and will wait one minute [01:00] after receiving the GPI before starting the event. Next come the Source and Destination fields. The uses of these will vary depending upon what type of event is being listed, but should normally be fairly self-evident. For example, for a record event, the source field indicates the audio source from which the recording is to be made, while the destination indicates the cat/cut combo to which the recording should be made. Some events may leave one or the other of these fields blank. Now come the day of the week fields. These indicate on which days of the week the listed event should be executed, followed by the Origin field, which is simply a readout of the Origin data of the events underlying cut. There are a number of other fields which follow, but these are less important for understanding the operation of RDCatch. At the bottom of the main window are various buttons. On the left-hand side, the Add, Edit and Delete buttons are used to manage events in the event list. Clicking the Scroll button toggles RDCatch into and out of 'scroll mode'. In this mode, the event list display will be advanced automatically so as to keep the first actively running event centered within the event list area. On the right hand side, in addition to Close, are three audition buttons. These buttons can be used to audition the head and tail of each cut referenced by an event, thus making it possible to quickly verify that a set of automatic recordings were properly executed. A new event can be added to the event list by simply clicking the Add button to bring up the Add Event Dialog (see ). Simply clicking the button that correspond to the desired type of event will create it. The Add Event Dialog Automated recordings are configured by means of the Edit Recording dialog (see ), which can be accessed either by clicking the Recording button in the Add Event dialog to create a new record event or by touching the Edit button to modify an existing event. The start parameters of each recording are configured in the 'Start Parameters' section. A recording can be programmed to start on the basis of the wall clock time, referred to the hard start time, or upon reception of a general-purpose input, or GPI event originated by a satellite receiver, tone decoder or other external device. Programming a hard start time is merely a matter of entering the desired start time, in 24 hour 'military' format. Programming a GPI start involves, in addition to entry of the GPI parameters themselves (matrix and GPI line numbers) that Window Start and Windows End times be entered, that define the 'window' during which reception of the appropriate GPI event will be 'recognized' by RDCatch. It is also optionally possible to specify a Start Delay between reception of the GPI event and the actual start of the recording. The Edit Recording Dialog The end parameters of each recording are configured in the 'End Parameters' section. A recording can be programmed to end on the basis of a hard time, its absolute length or in response to a GPI event. Programming of the Hard Time and Length parameters should be fairly self-explanatory, while the parameters needed to program a GPI event are similar to those used for the start parameters, with the exception of the Max Record Length setting, which limits the maximum length of the recording in the event that the expected GPI event is never received. If a record event is configured to use GPI for its start and Length or GPI for its end parameter, then it is possible to configure the event to make repeated, multiple recordings within a single event by checking the Allow Multiple Recordings Within This Window box in the 'Start Parameters' section. This can significantly reduce the amount of required record events when capturing material with high on-air turnover, such as newscasts or traffic reports. If the selected record deck (chosen in the Location drop-down menu at the top of the dialog) as been configured to operate with an audio switcher device, the appropriate audio input can be chosen from the Source drop-down menu. Each programmed recording must have a 'destination', a designated Cart/Cut which will hold the audio. The currently programmed destination is shown in the Destination field, and can be changed by clicking the Select button. A check should be placed next to each day of the week for which a recording should be made in the Active Days box. If no days are checked, then no recordings at all will be made. The record event will be actually executed only if Event Active check box (in the upper left corner of the dialog box) is ticked. By clearing this box, it's possible to 'bank' a record event without actually having it run, useful for events that are only used sporadically. For events that need to be executed only once, the Make OneShot box can be ticked. Such an event will execute just once, and then automatically delete itself from the event list. Automated playouts are configured by means of the Edit Playout dialog (see ), which can be accessed either by clicking the Playout button in the Add Event dialog to create a new record event or by touching the Edit button to modify an existing event. The process of configuring a playout is very similar to that for configuring a recording – see the above for details. The Edit Playout Dialog It's possible to use RDCatch to automatically upload and download material from both local and Internet-based servers. Automated downloads are configured by means of the Edit Download dialog, which can be accessed either by clicking the Download button in the Add Event dialog (see ) to create a new record event or by touching the Edit button to modify an existing event. The Edit Download Dialog With the exception of the Url, Username and Password controls, the process of configuring a download is very similar to that for configuring a recording – see the above for details. The Url control is used to specify the Uniform Resource Locater for the material to be downloaded. The following download types are supported: http:, ftp:, sftp: and file:. The Url field can also include wildcard characters that can be used to construct date-based URLs. The Username and Password fields are used to indicate the username and password required for access to the server referenced in the Url. For public web pages and anonymous FTP servers, these fields can be left blank. Automated uploads are configured by means of the Edit Upload dialog (see ), which can be accessed either by clicking the Upload button in the Add Event dialog to create a new record event or by touching the Edit button to modify an existing event. The following upload types are supported: ftp:, sftp: and file:. As with downloads, the Url field can also include wildcard characters that can be used to construct date-based URLs. The Edit Upload Dialog Configuration of an upload event is very similar to that of a download, with the addition of the Export Format control. This is used to set what file format should be used for the upload. Depending upon what software encoders have been installed by the system administrator, the following export types may be available: PCM16 Linear (*.wav) Free Lossless Audio Codec [FLAC] (*.flac) MPEG Layer 2 (*.mp2) MPEG Layer 3 (*.mp3) OggVorbis (*.ogg) The desired upload format and parameters are set by clicking the Set button. It's possible to configure the automatic execution of a Macro Cart by means of the Edit Cart Event dialog (see ), which can be accessed either by clicking the Macro Cart button in the Add Event dialog to create a new Macro Cart event or by touching the Edit button to modify an existing event. The process of configuring a macro cart event is very similar to that for configuring a recording – see above for details. The Edit Cart Event Dialog It's possible to configure an automatic operation on a switcher device by means of the Edit Switcher Event dialog (see ), which can be accessed either by clicking the Switch Event button in the Add Event dialog to create a new switch event or by touching the Edit button to modify an existing event. The Edit Switcher Event Dialog In addition to the usual fields, a switch event has Switch Matrix (the name of one of the switch matrices associated with the selected Location), Switch Input and Switch Output controls. When executed, a switch events causes a take operation to be performed on the specified switcher device between the specified input and output. It is possible to specify the input and output either by their alphanumeric names (assigned in RDAdmin) or by their absolute numbers.