Show Cue System

I'm working on yet another version of that Scottish play (again), and I'm trying to be clever...possibly too clever for my own good. The scenic designer has implemented a set with 3 big-screen LCDs strewn about, and the director is having graphic slides created for them. They hope to have the slides change on cue, and many of those changes will need to be synchronized with sound effects. Of course, the “systems integration” has been left to me. Here's the scoop so far:

My first thought was to build my show as I normally would, then stuff 3 extra video cards into a tower in addition to the local GPU to discretely address each individual screen. This has three major drawbacks:

- Cable length from the back of the house (where the audio computer would reside) to the stage is greater than 125', and 1920x1080 slides @ 60Hz wouldn't make it down an extra-long analog VGA cable without breakup, and long DVI cables (or CAT-5 extenders) would be cost prohibitive.

- Handling a heavy audio processing load plus 3 screens of video information is a LOT of number-crunching for one processor.

- A system failure would take down the entire show; both video and audio. Lame.

So, I started looking into other options. I've been playing with a bunch of Arduino programming, and I've been lurking in the forums quite a bit to see what I could use to accomplish this task. You may be familiar with the Debian Linux based Raspberry Pi: I thought it would be perfect for this application. It's simple, can be used as a black-box media server, and has an HDMI output. They seemed so cool that I bought 3 kits from Adafruit to play with. My thought was to strap one to the back of each screen with an inexpensive short HDMI cable and page though a Powerpoint-style slideshow with a custom button controller that I would wire up to the GPIO port(s). The slide data would be stored locally on each separate Raspberry Pi, so any system failure would just take down one screen.

Until I started thinking: What happens in rehearsal when the director wants to start at Act II-Scene 2? How will I know what slide I'm on? Do I have to count back XX slides and press the button that many times? Do I guess? Do I allow the menu on the screen for rehearsals? And I still can't guarantee synchronization with audio cues, since it'll be two separate button presses on different devices by different operators.

So you can see that isn't ideal; so I kept looking.

SCS can issue serial (RS232) and Telnet command strings. I came across a few Raspbian-tuned programs that may or may not do what I need...specifically RaspBMC (a Raspberry Pi-specific port of XBMC Media Server), Pi Presents (although I've spoken with its developer, and he thinks I may want to seek something else), many other command-line image viewers, and what I believe to be the most promising candidate: FIM. It's a simple image viewer that can load images straight to the framebuffer, and it can be controlled via command line. The only problem that I see (right now) is that it'll just load the file (assuming 1920x1080 JPEGs) straight to the screen and I won't have any control of a fade in or fade out. It'll just cut to a black slide.

Here's my current thinking:

- Network all 4 computers with Static IP addresses (Audio, Screen1, Screen2 & Screen3)

- Address each one individually via Telnet/SSH from within SCS. This way, the slides would be accessed via filenames that would recall correctly no matter where I start the show in the cuelist.

...and a long shot:

- Maybe (just maybe...) find a way to get some kind of transition in between slides.


I'm able to SSH into the Raspberry Pi(s) via PuTTY and issue the FIM commands, but I can't seem to mirror the same command from within SCS. I'm just about at the end of my computer savvy, especially when it comes to Linux and Telnet. I have no problem RTFM and learning really fast, but I need some help, and you guys may know (or have access to those that know) how to do this or have better, simpler ideas. I am open to other ideas, but the more tightly integrated with the audio software, the better. If I had to pull the trigger on it today, I'd be crossing my fingers and wiring up some buttons for the GPIO, but I think there's a slicker, more elegant answer, and I have a week or two to figure it out. Sadly, my programming skills/knowledge aren't up to snuff to come up with something fast, so I turn to you guys to help me figure out how to put the pieces together.

Thanks in advance for your consideration - thoughts?

I don't know that much about the raspberry pi but I think that can send them RS-232 over the UART pins you might need a level shifter to go between 12v and 5v but that might be your best bet.

wedgevlp wrote:I'm able to SSH into the Raspberry Pi(s) via PuTTY and issue the FIM commands, but I can't seem to mirror the same command from within SCS.

Can you give an example of what you are trying to do and why you are having difficulty doing this from SCS?

btw, another solution could be to have an 'SCS computer' for each LED screen, plus your master SCS computer, all linked by Telnet.

You could have one SCS computer with the multiple graphics cards near the screens to solve the cable length issue. Run audio out from it back to your FOH via a DI box or similar. Then use another computer at FOH to remote desktop into it to trigger the cues.

Quick update: Due to a time-crunch and the revelation that one of our operators owns (and is willing to let us use) a Lenovo W520 laptop with a dock that will allow us enough discrete display outputs, we're going to do the following:

The primary Audio SCS computer will live at FOH. I use multiple audio outputs, so I need it at FOH with a MOTU 828 strapped to it via Firewire. This machine will fire Telnet cues to the Video SCS machine onstage, which will keep my HDMI cable length under 50' to any screen. I'll use VNC or Remote Desktop Connection to monitor and/or edit the Video machine cues from my FOH position.

I'll continue to experiment with the Raspberry Pis, as I think they're going to be handy in our line of work for some video integration. Mike, I will post actual Telnet/SSH commands to you soon to show you what I'm trying to accomplish. I think the issue stems from an inability to address username and password via SSH. If it were just raw Telnet, it'd probably work.

Hi

I am starting this thread up again, because I have a similar request.

I just bought a Raspberry Pi 4, which has improved a lot since 2013. It can play 4k videos now.

I found this web page https://github.com/marsvaardig/osc-node which explains how to control Omxplayer on the Pi from Qlab with OSC messages. I tried to send the same messages from SCS instead of Qlab, but nothing happens. And I can´t find any OSC monitoring app for the Pi, so I have no idea what comes through, if anything. But I also now that Qlab is encoding the message as OSC on the way out, if you haven´t chosen "raw message". So I need help to know what to write in "Free format" in SCS instead of "/play /mnt/usb/my-video.mp4" (from the example).

Btw - I am a newbie with Raspberry Pi, Linux and OSC, so please explain in details.

Regards,

Brian

Brian, can you email me the SCS log file from a run in which you tried to send OSC messages to the Raspberry Pi?

Here you go!

Regards,

Brian

Brian,

I don't have a Raspberry Pi but please try this: Change your Control Send OSC Free Format message from
/play /mnt/usb/b.mp4
to
/play ,s /mnt/usb/b.mp4
Spaces are important.

The /play is the OSC 'address pattern', which is terminated by a space character. This is followed by a 'tag type string' which is preceded by a comma, so ,s means there is one string argument to follow. /mnt/usb/b.mp4 is that string argument.

If a string argument (eg your file path and name) contains any spaces then that string must be enclosed in double-quotes, eg
/play ,s "/mnt/usb files/b.mp4"
Double quotes can also be used even if there are no spaces, eg
/play ,s "/mnt/usb/b.mp4"