[RDD] A few modifications I'm considering (long)

Keith Thelen kthelen at kanabec.net
Fri Jan 2 09:29:36 EST 2015

Hello all!

After several years of casual involvement with Rivendell, I’m preparing to use it in a production environment where I will be directly engaged on a daily basis. In that process, I’ve found a few things in RDAirplay I’d like to add/change.

On the one hand, I have absolutely no experience in C or Qt (I’ve whipped up some slightly ugly chunks of PHP and Perl over the years; that’s about it). But on the other hand, I know that simply posting a bunch of ideas is unlikely to make them happen. So, in light of that, I’ve decided to have a go at performing the hacks myself.

Below is a description of what I’d like to accomplish. By posting it here, I’m hoping to get some input on whether the changes make sense (ie. things I may be overlooking, possible adjustments to my plans, etc) before I begin.

I’m also hoping that anyone who’s familiar with the Rivendell source, and who knows of any potential “gotchas” in the areas of code I’ll be digging into, might point them out to me.

### RDAirplay Default Clock Mode (12/24) ###

Currently, RDAirplay selects the 24-hour clock by default whenever started. Users can change to 12-hour by clicking the wallclock, but the setting is not retained after the application is closed.

For many users, a 24-hour clock is desirable. But for some (like us, for instance) it would be nicer if the 12-hour clock could be set to be the default.

Setting this variable to “12” would cause the 12-hour clock to be the initial selection when RDAirplay is started. Setting it to “24”, to some invalid value, or not specifying any value, would retain the current behavior (24-hour clock on launch).

### Cart Unload Delay ###

Currently, carts immediately disappear from the log machine once they finish playing.

Setting this variable to something other than zero would cause a pause of n milliseconds to be inserted between the end of the cart’s transition and its disappearance from the log machine. During the pause, the cart’s button would change colors (yellow? flashing red?), and if pushed would cause the cart to disappear immediately (same as current STOP button behavior).

Default setting would be zero, thus retaining current behavior unless specified.

The modification would only apply when the log machine is in LiveAssist or Manual mode. Automatic mode would not be affected.

This change would help reduce a persistent touchscreen issue I’ve been seeing over the years. Users would have their finger over the button for the cart they wished to start next, only to have the log machine advance a fraction of a second before they pressed the button, resulting in the cart they wished to play being skipped.

Another possible related hack: If ADD/DEL/MOVE/COPY is selected, hold carts in place until the ADD/DEL/MOVE/COPY operation is complete. As with carts currently playing, it would need to be made impossible to add a cart in front of a holding cart, move/delete a holding cart, etc.

### Change RDAirplay Log Columns ###
### Change Cart Selection Window Columns ###

The presence of several fields not used by us (AGENCY, LABEL, etc) - and the lack of other fields we would like to see (YEAR, ALBUM, etc) - is a bit of an annoyance. 

Fortunately, this one’s already been dealt with by others. WFMO has a patch on their website that does this, among several other things. Having that as a reference should make this particular issue easy to handle.

This could be related to the next item on the list; have yet to determine.

### Retain RDAirplay Log Column Settings ###
### Retain Cart Selection Window Columns/Size ###

Currently, changes to column width/order in RDAirplay’s log widgets, as well as the size of the Cart Selection window and column width/order in RDAirplay and other applications, are not retained after said application is closed.

Easy way, from the user perspective: Setting these variable to YES would cause the settings to be retained across application close/launch.

Harder for users, but perhaps easier for development: A number of variables could be set to statically assign these values (which I’d assume would be a matter of substituting the user-provided values for some currently hard-coded into the applications?).

Default setting would be to ignore this unless values are specified.

### RDAirplay Main Window Specify Size ###

Currently, the RDAirplay main window size seems to be fixed at 1024x738. This is acceptable as a minimum size, but a higher maximum would be desirable.

Setting this variable to something larger than the default would cause the window to “grow” outward, to the right and to the bottom.

Any new space to the right would be filled by expanding the width of the log widget, and by adding the appropriate amount of columns to the sound panel.

Any new space to the bottom would be filled in two ways.

On the bottom right, it’d be done by expanding the height of the log widget, and adding the appropriate number of rows to the sound panel (including moving the control buttons to the bottom of the window).

On the bottom left, it could perhaps be done by filling any empty space below the log machine and its buttons with a box displaying notes for upcoming carts - or maybe the contents of a pre-specified text file. Or, if technical and operational limits allow, it could be filled with more cart slots instead.

Since we don’t do anything to the size/shape of carts displayed in the log machine, any of the buttons, etc., we could potentially run into issues with things becoming too small to be usable, depending on screen size and resolution. But I think this set of parameters might be a decent compromise for the time being.

Note that this neither specifies nor recommends a user-adjustable window size. The window size would remain fixed from the user’s perspective (ie., no “draggable corners”).

### RDAirplay Main Window Specify Location ###

Currently, the RDAirplay main window seems to be set to open at 0,0 (upper left corner of display) when launched. Any movement of the window is not retained after said application is closed.

Setting this variable to some pair of coordinates would cause the window to appear at that location instead upon launch.

Though this could be used in tandem with the above suggestion, it would also be useful on its own. (Our screens are LCDs that run at 1280x1024, so the current window size means we end up manually moving the window to our preferred location - center of the screen - each time RDAirplay is started.)

That’s all! Sorry for the long post… Looking forward to your comments.

Keith Thelen
Kanabec Systems

More information about the Rivendell-dev mailing list