Re: [RDD] GPI question: update
The macros with the GE commands worked flawlessly this afternoon. I believe my client's GPI issue is solved. Rob ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] GPI question
So, this morning I decided to add a macro containing "GE 1 I 6 0!" as the first event after returning from the satellite feed. This does cause Rivendell to ignore subsequent closures form the satellite, but it doesn't execute fast enough to prevent contact bounce issues. I was able to skip as many as three events by applying the closure manually, even with the GE (we bring good things to life) command in place. Rob ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] GPI question
Greetings, I use gpi's in a live environment with at least five different networks using both transitions for different purposes without any problems, Once however with a particular sat receiver I had a issue with what appeared to be contact bonce starting more than one cart. Putting a sp 1000! After the PN in the macro cart solved the issue. On Dec 9, 2011 11:23 PM, "Rob Landry" <41001...@interpring.com> wrote: > > > On Fri, 9 Dec 2011, Rob Landry wrote: > > > I'm worried about things like contact bounce. The beauty of systems that > > act on states rather than transitions -- if it's low, go -- is that they > > tend to be more forgiving of hardware peculiarities. I've run across > > transition-sensitive boxes that wouldn't fire on anything but a hard > relay > > closure, and sometimes fired more than one event at a time due to contact > > bounce. > > I lied. I actually did some playing with the machine this evening rather > than waiting until tomorrow. > > The PN! command doesn't just work when rdairplay is stopped; a closure > received while an event is playing causes that event to end prematurely > and the next event to start. A bouncy closure will cause one or more > events to be skipped entirely. > > I'm going to re-read the Rivendell Operations Guide and see if there's a > way to make the closure conditional. If not, I need to wire an external > relay to disconnect the closure from the satellite receiver while the > satellite feed is not being aired. Otherwise, random closures received at > other times will cause PN!'s at undesired times. > > > Rob > ___ > Rivendell-dev mailing list > Rivendell-dev@lists.rivendellaudio.org > http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev > ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] GPI question
On Fri, 9 Dec 2011, Rob Landry wrote: > I'm worried about things like contact bounce. The beauty of systems that > act on states rather than transitions -- if it's low, go -- is that they > tend to be more forgiving of hardware peculiarities. I've run across > transition-sensitive boxes that wouldn't fire on anything but a hard relay > closure, and sometimes fired more than one event at a time due to contact > bounce. I lied. I actually did some playing with the machine this evening rather than waiting until tomorrow. The PN! command doesn't just work when rdairplay is stopped; a closure received while an event is playing causes that event to end prematurely and the next event to start. A bouncy closure will cause one or more events to be skipped entirely. I'm going to re-read the Rivendell Operations Guide and see if there's a way to make the closure conditional. If not, I need to wire an external relay to disconnect the closure from the satellite receiver while the satellite feed is not being aired. Otherwise, random closures received at other times will cause PN!'s at undesired times. Rob ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] GPI question
On Fri, 9 Dec 2011, Fred Gleason wrote: > On Dec 5, 2011, at 12:54 22, Rob Landry wrote: > >> If I understand correctly, it's the transition from one state to >> another that Rivendell sees, and not merely the state of the GPI being >> grounded or not. > Correct. In fact, it's possible to configure things so that completely > different actions happen when a line goes low->high and high->low. >> It may be that if the transition happens too slowly, Rivendell won't >> see it. That could be ugly. > This will be totally a function of the particular hardware in use. If > the hardware tells the software that a transition happened, then it's > acted upon. If not, then not. No 'in-betweens' here. I'm worried about things like contact bounce. The beauty of systems that act on states rather than transitions -- if it's low, go -- is that they tend to be more forgiving of hardware peculiarities. I've run across transition-sensitive boxes that wouldn't fire on anything but a hard relay closure, and sometimes fired more than one event at a time due to contact bounce. Today I assembled an exact duplicate of my client's system in my living room, complete with Broadcast Tools ACS8.2 switcher. I'm going to experiment with it tomorrow to see what, if anything, I need to build in the way of an eternal interface. I do wish there were a way of "turning off" inputs during times when the desired satellite feed isn't on. I need to make sure that closures received during other programs don't cause events in my log to be truncated or skipped. Rob ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] GPI question
On Dec 5, 2011, at 12:54 22, Rob Landry wrote: > If I understand correctly, it's the transition from one state to another > that Rivendell sees, and not merely the state of the GPI being grounded or > not. Correct. In fact, it's possible to configure things so that completely different actions happen when a line goes low->high and high->low. > It may be that if the transition happens too slowly, Rivendell won't > see it. That could be ugly. This will be totally a function of the particular hardware in use. If the hardware tells the software that a transition happened, then it's acted upon. If not, then not. No 'in-betweens' here. Cheers! |-| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |-| | Do not try to think outside of the box. That's impossible. Instead, | | realise the truth. There is no box. | | --Quoted by "larsmjoh" on GrokLaw.net | |-| ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] GPI question
On Mon, 2011-12-05 at 12:54 -0500, Rob Landry wrote: > It sounds like there aren't many Rivendell stations that put satellite > feeds on the air in real time. Otherwise, someone would have encountered > this problem before. I'd be surprised at that, but I guess that's possible. I actually have a pair of [redundant] Rivendell systems (only one of which I've upgraded to the appliance so far), and I have closures from three different satellite receivers that I've been planning to (one day) connect up to my Rivendell systems for voice-over liner purposes: it's currently running on hard-timed events only so no random/dynamic liners are running at the moment even though I've fully built the configuration for them and manually simulated the closures. Question: How long are your pulses? Are you trying to use latched input triggers, or momentary? My input triggers are one-second duration; I've never heard that anyone else using trigger inputs has had this type of problem, so I'm wondering if you've got something weird about your input triggers. Really though, OTOH, if the Macro *is* firing based on a trigger input but some events in the Macro aren't being executed, then Rivendell (specifically, the ripcd process) properly detected the input trigger state change and signaled the rest of the system to respond appropriately. A failure of something within the macro would be another problem other than the possibility of the input trigger not being seen properly. Again, the logs are your best diagnostic tool here. Hope this helps. -- Sherrod Munday Sky Angel ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] GPI question
On Mon, 5 Dec 2011, Sherrod Munday wrote: > On Sat, 2011-12-03 at 20:32 -0500, Rob Landry wrote: >> If I manually short the GPI input to ground, sometimes nothing at all >> happens, and sometimes the commands work as they are supposed to. > Your word "sometimes" concerns me... The whole point of the computer > *auto*mation is that it's supposed to be automatic and reliable, with > reproducible results. It doesn't sound like you've been able to achieve > that yet. (And, yes, I know *very* well how frustrating that can be.) If I understand correctly, it's the transition from one state to another that Rivendell sees, and not merely the state of the GPI being grounded or not. It may be that if the transition happens too slowly, Rivendell won't see it. That could be ugly. The same switcher connected to a Scott SS32 system behaves differently: when a GPI is grounded, you see a corresponding dot on the SS32 configuration page turn red. It stays red as long as the GPI is grounded, and turns off when the connection to ground is broken. > I'd suggest doing some experimentation with an offline system to try to > determine if the transition type, cart type, etc. in the log/playlist > may have any effect on the reliability of the process. As it happens, I have such a system at home, complete with another ACS8.2 switcher. When I have some free time, I'll play with it and see what I can find out. It sounds like there aren't many Rivendell stations that put satellite feeds on the air in real time. Otherwise, someone would have encountered this problem before. Rob ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] GPI question
On Sat, 2011-12-03 at 20:32 -0500, Rob Landry wrote: > If I manually short the GPI input to ground, sometimes nothing at all > happens, and sometimes the commands work as they are supposed to. Your word "sometimes" concerns me... The whole point of the computer *auto*mation is that it's supposed to be automatic and reliable, with reproducible results. It doesn't sound like you've been able to achieve that yet. (And, yes, I know *very* well how frustrating that can be.) > But when the opera cue closure fired, the first command put Rivendell back > on line all right, but the second command didn't have any effect. If the first "ST" command in the macro makes the switcher go back as expected, then it sounds like the macro is actually executing (sometimes). But if the macro fires and the first line executes, but the "PN" command does not work, that's somewhat puzzling. I'd suggest doing some experimentation with an offline system to try to determine if the transition type, cart type, etc. in the log/playlist may have any effect on the reliability of the process. And, as always, check your logs thoroughly and carefully. If you cannot resolve it from the logs yourself, you may want to post the relevant sections of the logged output of ripcd and rdairplay to the list for some additional eyes and thoughts. -- Sherrod Munday Sky Angel ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] GPI question
On Fri, 2 Dec 2011, Sherrod Munday wrote: > On Thu, 2011-12-01 at 13:25 -0500, Rob Landry wrote: >> will Rivendell proceed to the next >> event on its log when the cart finishes? Or will it just sit and wait >> for another closure? > > If I understand correctly, the question of triggering the next cart from > the GPI is really not the focus of your question. I think you're > primarily interested in how to keep Rivendell from continuing on to the > next cart automatically, or how to make it do it when you want to, > correct? No; my problem is getting it to resume. One of my clients takes an opera broadcast Saturday afternoons. Today was the first one of the season. At the appropriate time, Rivendell executes a macro cart containing the command: ST 1 3 1! That puts the opera on the air. The next event in the playlist has a STOP transition, and that stops Rivendell while the opera plays. The problem arises at the next break, when the opera throws it back to local stations for spots. I'm sunning a Broadcast Tools ACS8.2 switcher, and I had GPI input #6 on the switcher set up to play cart 999001, which is a macro cart with these commands: ST 1 8 1! PN 1! This is supposed to tell the switcher to put Rivendell back on line and then resume playing local events. However, it's not reliable. If I manually short the GPI input to ground, sometimes nothing at all happens, and sometimes the commands work as they are supposed to. But when the opera cue closure fired, the first command put Rivendell back on line all right, but the second command didn't have any effect. My suspicion is that mine is not the proper way to do this sort of thing. How do Rivendell stations that use satellite feeds handle break closures? Rob ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] GPI question
On Thu, 2011-12-01 at 13:25 -0500, Rob Landry wrote: > will Rivendell proceed to the next > event on its log when the cart finishes? Or will it just sit and wait > for another closure? If I understand correctly, the question of triggering the next cart from the GPI is really not the focus of your question. I think you're primarily interested in how to keep Rivendell from continuing on to the next cart automatically, or how to make it do it when you want to, correct? If so, the answer is that it depends on the transition type for the next event in the log currently loaded and running in RDAirplay. If it's STOP, RDAirplay will stop at the end of the currently-playing cart and wait for the next start command (either from the UI or RML or GPI, etc.). If the transition type is PLAY or SEGUE, etc. then it will continue on to the next event without stopping. Does this help? -- +--+--+ | Sherrod Munday | | | Senior VP, Engineering | (423) 396-8130 (W) | | Sky Angel U.S., LLC | | +--+--+ ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
[RDD] GPI question
I want to have Rivendell switch a remote audio feed on the air and stop. When it gets a closure from the remote location, signallig the end of the remote feed, I want Rivendell to resume playing cuts from its log. The first part I have figured out. But the second still eludes me. I can define a GPI to trigger a cart, but will Rivendell proceed to the next event on its log when the cart finishes? Or will it just sit and wait for another closure? Rob ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
