Getting Started with Tally Arbiter and OBS Studio

Uncategorized 15 comments

I was asked recently over on the TechMinistry YouTube Channel to post a tutorial on how to get started using Tally Arbiter with OBS Studio.

Here’s that video:

15 comments

  1. Any chance you plan to add support for the Panasonic HS-AW50. It appears to have a pretty simple protocol. Or can you guide me on how I would go about adding support?

    Like

    Reply

    1. Hello Amit! You’re right, it does look like a simple TCP protocol. The key factor would be whether we have to poll the device for tally data on an interval or if it will return device state over the socket for as long as we remain connected. Do you know?

      Like

      Reply

  2. Hey there, loving this!

    So… for our church we have an ATEM (mini) handling camera switching, which is connected via USB to our Mac running OBS.

    How do It route it so the cameras are sources on the ATEM, but will only register as ‘PGM’ or ‘PVW’ if I’ve activate the ATEM as a source on OBS? I think I’m not understanding something in the routing and settings.

    Like

    Reply

      1. Thanks Joseph, Currently, I think this would be mainly helpful for our facilitators to know when the camera goes ‘live’ after we’ve cut back from video content…

        In fairness – we’re moving to do the service as a live event again rather than a live studio – so presenters will always be live as it were and only camera people will need to know if the feed is active… so I could switch to an empty input on the ATEM to let cameras know they’re not on.

        Like

  3. Darn! You beat me to the luggage joke.

    Any chance you can do one more level of backgrounder — or point to someone elses — on how to make sure the build environment is correct on a Mac? You gloss over npm and node, and it’s not clear what they come from… And you comment on them on the github page without mentioning whether they’re Mac-specific.

    Like

    Reply

  4. Question: npm install says to run npm audit, which says this:

    # Run npm install socket.io@4.0.1 to resolve 1 vulnerability
    SEMVER WARNING: Recommended action is a potentially breaking change
    ┌───────────────┬──────────────────────────────────────────────────────────────┐
    │ Moderate │ Insecure Default Configuration │
    ├───────────────┼──────────────────────────────────────────────────────────────┤
    │ Package │ socket.io │
    ├───────────────┼──────────────────────────────────────────────────────────────┤
    │ Dependency of │ socket.io │
    ├───────────────┼──────────────────────────────────────────────────────────────┤
    │ Path │ socket.io │
    ├───────────────┼──────────────────────────────────────────────────────────────┤
    │ More info │ https://npmjs.com/advisories/1609 │
    └───────────────┴──────────────────────────────────────────────────────────────┘

    That’s underneath your layer of code, right? Does it sound critical-path to you? Should I audit-fix it, or just ignore?

    Like

    Reply

    2. (I assumed audit fix -force, and that seems to be working ok so far, but I thought you’d like to know. OS/X 10.13.6, and I think I’m fenced there by an app limitation that won’t get broken.)

      Like

      Reply

  5. Oh. So that was the wrong choice. Oops. What I get for forging ahead. How do I back the install out to redo it, there?

    Like

    Reply

  6. Well, I did that, a couple times, and these times it did *not* prompt me about the troublesome item… but I decided to ignore the non-prompt, and forge ahead anyway, and it seems to be working fine against my ATEM Mini Pro Iso, except for 2 things, which are probably trivial:

    1) The running program now says “reconnect” on a new line every second or few, amongst the log data, which it didn’t do on the first install, and

    2) It doesn’t seem to properly introspect the Source pulldown, when creating the Input on the switcher as a device; I can just put in 1 (through 4) and it seems to work ok, but I assumed that pulldown would show the available input designators, and it doesn’t. No biggie, since it works.

    One suggestion: it’s possible — at least on the ATEM and probably most places — to have a source in both Program and Preview. That presently makes the tally yellow. I’d assert that Program should take priority over Preview there, and the tally should stay red; it’s not the talent nor the camera operator’s business that you happen to have both buttons in the same place. I often do it on purpose, since it unlights the Take and Auto buttons on the Mini, making the panel darker.

    Very nice little package, for all of my don’t-know-how-to-set-it-ups. 🙂 Thanks for your work on this.

    Like

    Reply

Leave a Reply