Lorne, thanks for the input. Not sure we want to go this way, but I will comment on my thinking for the future and for the benefit of any interested parties anyway.
On Sat, Jun 3, 2017 at 12:49 PM, Lorne Tyndale <ltynd...@tyndaleweb.com> wrote: > Drew, > > I just had a thought - with Rivendell maybe it can be easier then all of > us are thinking. > > I have not tried any of this in real life, just theorizing here. But > for some reason I just had a thought on another subject and realized it > might be what you're looking for. > > -Have your "remote" with the ability to VPN into your "station" network > and see your Rivendell server > This should be doable. > > -Set up your "remote" rivendell machine with a full copy of Rivendell, > but accessing the database on the main server. For this to work, you > might need to have a local copy of /var/snd - I've run into challenges > getting a fast enough mount when at a remote location, but it might work > via a mount too > I would not want to try a mount, but a local copy that was kept up to date every night should be doable. > > -Set your "remote" machine to use the Core Audio Engine on the main > server back at your station (rdadmin --> Manage Hosts --> Core Audio > Engine). Either all of my Rivendell systems are too old to have this setting or it is not there in the chain. > This means that if you play something on your "remote" machine > it'll use the audio engine back / audio card back at the studio, but use > the local RDAirplay for on-screen display and control > The question is, where will it pull the wav file from? The studio's /var/snd, or the local /var/snd. For this to make sense, I think you would wan't the studio's /var/snd. > > -Use Jack at each end - have Rivendell routed to use Jack at the studio. > Not always doable if we have an ASI card in the studio. Or have the differences between the ASI "model" and the alsa/jack "model" been sorted? > Have OpenOB set to use Jack. Run OpenOB twice on each end - one as the > Send and one as the Receive. Then you have a 2 way audio link between > your studio and your remote site. You can then route your Rivendell > audio output to both your sound card plus your OpenOB send at the studio > and hear what's going over the air. At your remote end you can have > your OpenOB Receive going to your sound card output. Your OpenOB Send > can be set up to send your mic audio back to the studio. > > -When on remote, you'd simply need to have the Studio RDAirplay stop > after what it is playing, and route its OpenOB Receive to the audio > output. Start up RDAirplay at the remote site, load the same log you'd > load in the studio and do a "make next" to bring your "remote" log to > the appropriate spot. > > -when you hit "start" or such on the remote RDAirplay the audio will get > played at the studio machine (remember - we've set the remote machine to > use the studio's audio engine). You'll be able to hear the back-cue via > your OpenOB receive coming back from the studio. > > -when you want the jock to go "live" from the remote, you simply have to > make RDAirplay stop (just as you would when in the studio) and turn on > the remote mic. The OpenOB Send will send your mic audio back down the > pipe to your studio and out to your output (since it doesn't go through > Rivendell at all it'll also have the added bonus of creating a > mix-minux) > I will have to think this last bit all through very carefully. > > To make it pretty you'd want to write some scripts to: > > -Estalish the VPN link from remote > -Start up and route to Jack as needed OpenOB on each end with the needed > number of instances > -RML the ability to inserrt a stop in the main log at the "studio" > machine (for when the remote starts) > -RML the ability to jump to the appropriate part of the log in the > Studio machine and resume playback on its RDAirplay(for when the remote > is done) > -Test to see what happens if / when the link between the sites gets > unexpectedly disconnected, crashes, etc. > > Definitely would need a bunch of testing before putting it live, but I > can see if it works in reality then I think there is a possiblity here. > > On the other hand - using Jack on each end with OpenOB for the > transport, you could do something similar by VPN'ing and VNCing into the > main RDAirplay machine, as you were first thinking. then all you'd need > to do is get the Jack audio routing working - which can be scripted with > jack_connect (or there is also an RML which can do jack connections, > although I've had limited luck in making that work) > This is where we are with our thinking / testing so far: (I just thought of a problem arising from the fact that our "real" machine has an ASI card while our "test" machine does not.) Let's talk the test set up first. Remote side: Mic going into a mixer. Outputs of mixer going to a USB sound card on a pi 3. OpenOB running on the pi 3 (alsa mode, I was ding jack and all was working fine a day ago iirc, but today jack / qjackctl seems to be causing reboots so I switched to alsa.) OpenOB sending using opus codec to OpenOB on the other side of a VPN. openob -v 10.8.0.1 test-tx-node test-link tx 10.8.0.1 -a alsa -d hw:1,0 Studio side: This machine has 2 different USB sound cards. OpenOB running on one in alsa mode. openob -v 10.8.0.1 test-rx-node test-link rx -a alsa -d hw:0,0 rdAirPlay running on the other sound card using jack. The line out of the OpenOB card is going into the line in of the rivendell sound card. Also running in jack is Jack Mixer and meterbridge. Jack has been set up with 2 input channels. The rdairplay outputs are fed into channel 1 and the sound card's inputs are fed into channel 2. (Remember: OpenOB sound card line out -> rivendell jack sound card line in -> Jack Mixer channel 2.) The main outs of Jack Mixer (mixed rdairplay and remote mic sound) are sent to system out which is currently connected to a speaker but which represents the rest of the "air chain." There are three buttons set up on panel S:1. S:1 C1 R1 -> Remote Music Bed: Plays a music cart that has our bed in it S:1 C1 R2 -> Insert Inline Go Remote: Plays cart 050006 S:1 C1 R3 -> End Remote: Plays cart 050003 Cart 050006 is a macro cart with 1 line: 001 PX 1 050004! Cart 050003 is a macro cart with 1 line: 001 RN /home/rduser/endremote.sh! Cart 050004 is a macro cart with 2 lines: 001 RN /home/rduser/inlinegoremote.sh! 002 SP 1000! IIRC, the second line was needed to stop it from eating the next entry in the log. Current contents of the bash scripts: inlinegoremote.sh cart 050004: #!/bin/bash # inlinegoremote.sh # rml commands to start a remote rmlsend PM\ 1\! rmlsend PP\ S1\ 1\ 1\! rmlsend PD\ S1\ 1\ 1\ -80\ 1\! rmlsend PD\ S1\ 1\ 1\ 0\ 10000\! #rmlsend SP\ 100\! #rmlsend PD\ S1\ 1\ 1\ 0\ 100000\! #rmlsend SP\ 1000\! rmlsend PS\ 1\ 10000\! rmlsend SP\ 10\! endremote.sh cart 050003: #!/bin/bash # endremote.sh # rml commands to end a remote rmlsend PM\ 2\! rmlsend PN\ 1\! #rmlsend PD\ S1\ 1\ 1\ -40\ 15000\! rmlsend PT\ S1\ 1\ 1\ 0\ 0\ 5000\! How we are using it so far: We keep the mic channel in Jack Mixer muted while the log is playing. When the song just before we want to go to a remote is playing, we click on: S:1 C1 R2 -> Insert Inline Go Remote: Plays cart 050006 which runs: PX 1 050004! which puts cart 050004 in the log right after the song that is playing with a segue transition (that is our set default.) As the current song is about to end, we unmute the Jack Mixer channel 2, the mic channel. When the current song ends / hits the segue point? The inserted inline macro cart 050004 fires which runs the bash script inlinegoremote.sh... We can start talking after we unmute the mic, while the song in the log is still playing and during the transition to the music bed if we like. What we are trying to get smooth: As the song is fading down, the bed should fire low and fade up (with overlap if we get it right.) We talk, talk, talk, as the bed plays. When we are done, we click on S:1 C1 R3 -> End Remote: Plays cart 050003 What we are trying to get smooth: We want the bed to fade down and end and the next song in the log to fire and fade in as the bed is fading down. I am not sure I understand the interaction of all of the markers set on the cuts in rdlibrary, the seque transition, and the ducking and fading of the panel buttons in the rml commands to get this properly smooth at this point. If anyone understands this stuff deeply, I would like some pointers. If anyone would like to work together to make a nice little tutorial covering this in more detail than the manual covers it, please let me know. all the best, drew > Cheers, > > Lorne Tyndale > > > > > > Lorne, > > > > thank you for your answer. > > > > On Thu, Jun 1, 2017 at 12:02 PM, Lorne Tyndale <ltynd...@tyndaleweb.com> > > wrote: > > > > > Hi, > > > > > > I think you're making this more difficult then it needs to be. > > > > > > > Possibly. > > > > > > > > > > What I'd do: > > > > > > -Have the audio coming from your remote on a separate channel on your > > > console in your on-air studio > > > > > > > We want to be able to do this in an air studio that does not have a > working > > console. > > > > > > > > -Have that channel set up so that Rivendell can turn that remote > channel > > > on / off via GPIO's > > > > > > > I am looking at learning the local audio card switcher functionality to > see > > if I can do things that way. > > > > > > > > -For your remote site gear, since you're going to have a computer > > > already (to be able to see the on-air machine RDAirplay via VNC) use a > > > Linux box, install a "remote" copy of Rivendell on it that includes > your > > > music bed audio > > > > > > > > > > > > > > > -At your remote site connect your mic and your "remote computer" audio > > > into a small mixer > > > > > > We are planning on doing this. > > > > > > > (or if you use something like a Tieline > > > Commander/iMix or Comrex Access with the mixer add on, just use the > > > inputs on that). If needed you can usually find inexpensive Bheringer > > > or Mackie's that have 4 to 8 channels that'll work for this type of > > > application > > > > > > > We are currently looking at a small Behringer USB mixer. > > > > > > > > When you want to go live from the remote site, you can have the remote > > > computer send the RML back to your studio computer to trigger your GPO > > > to turn on your "remote" channel. > > > > > > I had not considered doing this remotely. I was doing the RML on the > > airplay machine via panel buttons. I will have to ponder this. > > > > > > > It can stop your playout from the > > > on-air studio Rivendell system or you could even have it set up that > > > when you want to go live from remote it'll insert an item with a "stop" > > > as the next item in the log (that is if you don't want to schedule the > > > breaks in the log before the remote, which might be easier). > > > > > > I have made some improvements today from where I started this morning. > > > > I have one button that inserts a macro "next" in the playing log. When > the > > macro runs, it puts the machine in LiveAssist mode. It then starts the > bed > > music. It then stops the log machine (I think this is redundant as I > should > > already be in live assist mode.) It then sleeps for a bit. I had to add > the > > sleep bit because the next item in the log was being "eaten." > > > > > > > Do the > > > mixing of the voice / bed at the remote site with the mixer you have > > > there (you can have that audio on the remote site's Rivendell box) and > > > send all that audio back to your studio. > > > > > > I will try this. I am not sure we want the bed being compressed and > > uncompressed on the link. > > > > > > > When you want the studio to > > > resume playout send another RML down the pipe to turn the "remote" > > > channel back off and do a Play Next in Rivendell. Your audio starts > > > back up coming from your on-air Rivendell machine. > > > > > > > Again, I have a button on the sound panel to do this. This button puts > the > > machine back into Automatic mode. It then starts the next cart in the > log. > > It then fades the bed down. It then stop the bed playing. > > > > > > > > > The biggest concern would be if your network drops for some reason - > you > > > could end up with dead air. But the same situation could happen with > > > the setup you've described below. As a backup it might be an idea to > > > tie it all into a silence detector which would - after a certain amount > > > of time - send your on-air machine a "play next" command in the event > > > that something like that happens. > > > > > > > Thank you for this idea of the silence detector. I will have to figure > out > > how to do it. If I have a looping bed or a long enough bed, I would not > > want to detect silence on the rdairplay output. I think I would need to > > detect it on the incoming audio from the remote site. > > > > I think if I figure the switcher stuff out, I will need to grab the > remote > > input on remote start and release it on remote end. > > > > all the best, > > > > drew > > > > > > > Lorne Tyndale > > > > > > > > > > > > > > Hi, > > > > > > > > I am looking for thoughts on possible ways to do this. > > > > > > > > Let's say we go on a remote and have no one in the air studio. > > > > > > > > We can remote into (say vnc over an ssh tunnel) the rdairplay > machine to > > > > control things. > > > > > > > > We can monitor the broadcast signal from an FM receiver at the remote > > > > location. > > > > > > > > We can set a music bed on an RDAirPlay sound panel button. > > > > We can set a music bed on an RDPanel sound panel button. > > > > We can set a music bed in an RDCartSlot cart slot. > > > > > > > > We can set up a macro to go to a remote break and put it on an > RDAirPlay > > > > sound panel button. > > > > We can set up a macro to come back from a remote break and put it > on an > > > > RDAirPlay sound panel button. > > > > > > > > Consider: > > > > > > > > a macro with this command: > > > > > > > > RN /home/rduser/goremote.sh! > > > > > > > > will fire the following bashscript > > > > > > > > #!/bin/bash > > > > # goremote.sh > > > > # rml commands to go to start a remote > > > > > > > > rmlsend PS\ 1\! > > > > rmlsend PP\ S1\ 1\ 1\! > > > > > > > > and: > > > > > > > > a macro with this command: > > > > > > > > RN /home/rduser/endremote.sh! > > > > > > > > will fire the following bashscript > > > > > > > > #!/bin/bash > > > > # endremote.sh > > > > # rml commands to go to end a remote > > > > > > > > rmlsend PT\ S1\ 1\ 1\! > > > > rmlsend PN\ 1\! > > > > > > > > When you are ready to go to a break, you switch to LiveAssist mode > and > > > > click on the goremote button on the sound panel in rdairplay when the > > > > current cart is almost over. the cart will end and the music bed will > > > start. > > > > > > > > When you are ready to end the remote segment, you switch to Automatic > > > mode > > > > and click on the endremote button on the sound panel in rdairplay. > > > > > > > > Crude and nasty but it can kind of work. > > > > > > > > ***IMPORTANT*** This currently ignores the very important issue of > how we > > > > get the remote audio into rdairplay to play over the top of the > music bed > > > > in the first place but that is for a later discussion. > > > > > > > > To make this better: > > > > > > > > 1. How can we FADE DOWN the LOG machine and FADE UP the BED when > going > > > into > > > > the remote break? > > > > 2. How can we loop the bed so that we can use a shorter audio file > in the > > > > BED cart? (If we cannot do this, we will need a bed that is longer > than > > > any > > > > break we will ever have. > > > > 3. How can we FADE DOWN the BED and FADE UP the LOG machine when > coming > > > out > > > > of the remote break? > > > > > > > > What questions should I be asking that I am not? > > > > What are better ways to do this? > > > > > > > > Would it be better to put the macro carts for going into and out of > the > > > > breaks into the log in the correct spot rather than firing manually > from > > > > the sound panel? > > > > > > > > Etc. > > > > > > > > all the best, > > > > > > > > drew > > > > -- > > > > Enjoy great *Bahamian Music* at: > > > > Bahamain Or Nuttin - http://www.bahamianornuttin.com > > > > <http://www.bahamianornuttin.com/><hr>_____________________ > > > __________________________ > > > > Rivendell-dev mailing list > > > > Rivendell-dev@lists.rivendellaudio.org > > > > http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev > > > > > > > > > > > -- > > Enjoy great *Bahamian Music* at: > > Bahamain Or Nuttin - http://www.bahamianornuttin.com > > <http://www.bahamianornuttin.com/> > -- Enjoy great *Bahamian Music* at: Bahamain Or Nuttin - http://www.bahamianornuttin.com <http://www.bahamianornuttin.com/>
_______________________________________________ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
