TALLY

[tomspace]

Hi It would be great to have access to input tally status as OSC. I'm currently doing tally based on pgm bus selection, but this obviously doesn't work for sources which are in an USK PIP or whatever.

[SteffeyDev]

@danielbuechele Is this related to the feature you had in atemOSC initially?

[danielbuechele]

No, I had my own implementation for Tallys, when the ATEMs didn't offer support for this. But some devices now have a way to connect Tally lights. However, I am not sure if the SDK gives us this information. Basically, it should give us a list of all sources which are used in the current program feed.

[SteffeyDev]

It looks like we can use IBMDSwitcherInput::IsProgramTallied to query each input. Maybe we can make a new OSC method that returns a list of tallied inputs by asking each input if it is tallied. This could help for #143

[bnmohr]

+1 for Tally, including preview as well which I know is another open request.

It would be super helpful to get a pushed tally rather than polled. Regarding the SDK, everything I read about tally that is not BMD's own tally box, refers to this reverse engineering: https://www.skaarhoj.com/fileadmin/BMDPROTOCOL.html

I'm not sure if their tally system links in like the BMD box where you tell the switcher the IP of the tally box and it pushes it out, or just constantly pings the switcher to get a status.

[high-solutions]

After reading this and https://github.com/danielbuechele/atemOSC/issues/159 my mind was going to a feedback system for qlab cues/ obs scene's following selected camera (for different overlays per camera, or even different on-pc green screen background angels per camera) and also x32 switching audio scenes / mics https://github.com/danielbuechele/atemOSC/issues/143.

I was thinking, I need this!! Why isn't this implemented?!?! But this is actually already implemented into AtemOSC how i see now!

with the help from osculator i managed to read and reroute the feedback OSC. This works identical as the pgm program selection. This is what AtemOSC sends back on a preview change (previewed camera 3):

/atem/preview/1 0.00 /atem/preview/2 0.00 /atem/preview/3 1.00 /atem/preview/4 0.00

So what i did in osculator is if preview "#" is higher than 0.5 send OSC > qlab cue "#" so in qlab it launches cue: "preview number 3".

it also gives feedback on USK/DSK On-air status: 1 or 0, sadly not which source is used in it but if you change the source it wil give osc feedback which source is selected. So knowing this maybe it shouldn't be to difficult to make this possible. (In my case i would store changed-states of fill and key sources trough osculator and mark them tallied when ever the USK/DSK switches On-Air. The disadvantage would be that you should make a start-up routine where al sources from USK/DSK & Pip would be reloaded for correct feedback on start but i could live with that. Maybe this could be made easier from within AtemOSC.)

Of course you don't necessarily need osculator if your software can listen/learn osc commands (like qlab). It just makes it pretty easy to reroute osc to desired output. I think it's just a matter of translating the right info from AtemOSC to your desired tally system right?

To be honest knowing this is working for me really made my week!

[bnmohr]

Yes, I was meaning to come back and say I have found a solution to this which does involve running through OSCulator. Also because I did not realize that atemOSC pushed out program and preview changes without being polled by request. Meaning if I use the atem software controller to make a change- that change is pushed out through atemOSC. That was not clear to me from descriptions and documentation. So I agree reverse engineering the Tally protocol may not be necessary because it can be built by funneling the current program and preview information exactly as you describe. I also have been able to use the existing features to serve my needs and indeed, I was pretty giddy to see auto selection of lower thirds...

Qlab is limited in "learning" osc- you really need to stick to their own addresses to fire cues so I am using OSCulator to translate. It's not a problem because I think I also need osculator for other things.

[high-solutions]

yeah you are completely right about qlab, it was more of a general software example then to promote qlab in this way, my bad. Eventually you need to find your own best solution according to your setup and wishes i think.

I'm trying to get this to work with OBS studio but because it has limited shortkeys/midi/osc implementations on osx it is way more difficult then getting it to work with qlab. Can i ask what you are using for triggering lower thirds?

[randallpacker]

Greetings @high-solutions have been enjoying your posts. I am wondering if you are familiar with Max/MSP/Jitter from Cycling 74, which I use as a master control for all my interactions with ATEMOSC. Max has OSC functionality and it is one of the most powerful platforms for integrating audio, video, interactivity, and networking. Via Max, I send commands from Ableton Live (music) and VDMX (video) to ATEMOSC using sequencing, midi controllers and keyboard: all coordinated musically in time. I would suggest checking it out as it is very comprehensive, stable, and well documented software package.

[dappertutto]

a showcase of different use cases could be a wonderful way to introduce new users to examples of diverse possibilities with atemOSC. This project has reached a new level (owed in large part to Pete Steffey’s hard work, from what I can tell!).

Personally, I’ve used it with troikatronix’ media software ‘Isadora’ and Ableton/Cycling ’74’s ‘Max’. Another free software that I’m certain would work well is pure data https://puredata.info/.

best, d

On Jun 8, 2020, at 10:54 AM, high-solutions notifications@github.com wrote:

yeah you are completely right about qlab, it was more of a general software example then to promote qlab in this way, my bad. Eventually you need to find your own best solution according to your setup and wishes i think.

I'm trying to get this to work with OBS studio but because it has limited shortkeys/midi/osc implementations on osx it is way more difficult then getting it to work with qlab. Can i ask what you are using for triggering lower thirds?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/danielbuechele/atemOSC/issues/108#issuecomment-640779820, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFAXQVDPYIDWANRJ2EZ2ZKDRVUQTRANCNFSM4FWIGSYQ.

[randallpacker]

I want to ditto a big thanks to @SteffeyDev Peter's amazing work. ATEMOSC is at the very heart of my live Internet performance work and it wouldn't be possible without it.

[high-solutions]

Not only amazing but also fast work! Only here a few days but great response from @SteffeyDev !! This made me love my Atem a lot more.

I have used Max 8 for a performance but to be honest it's a little bit too much hassle for me. Yes you could do a lot and you can make a lot of custom things for your self, but it takes too much time for me to learn it and make everything i need. I'm using ableton/ qlab/ jands vista (light) or grand ma2 and the x32 systems from Behringer/midas, and to be honest Qlab is the most useful for me mostly for the incredible fast workflow you can have with it and still be flexible. And the apple-scripting osc audio video combo works great for me. it has it's shortcomings but you learn to workaround i guess.

Not that i think max8 couldn't do that but for me to switch or maybe learn them both is just to much i think, i'm not sure my knowledge of Qlab wil be surpassed by another program and thats fine for me for now. Also i did buy a few licenses for Qlab and i think financially i would rather buy a new camera then adding software on my bloated mac ;)

[bnmohr]

Can i ask what you are using for triggering lower thirds? Can you clarify this question? You mean what will cause the L3 to appear? I haven't decided what the final trigger will be but my suspicion is a streamdeck button. I don't want them to appear every single video change so it will still be a manual call, but the selection, fade up, wait and fade out can all be automated by qlab so that I only need to call that I want it to appear.

I will second that in my workflow, max/msp is major overkill for the task at hand. If I need to start broadcasting OSC to multiple changing targets I may change my mind but even then I may still only use it as a broadcaster rather than translator. OSCulator is well organized and clean for what it does, I see no reason to reinvent the wheel. I save max for custom processes that can't be built in other standard and supported software.

As far as demonstrating use cases- I will also either automate from qlab the atem to switch to my video playback input and set audio mixer settings when switching between live panels and playback, and then restore back to live panel- or with the program selection functions, set a lock that playback cannot be started until it is the selected program on the switcher. I can also of course build this complex switches as macros and fire the macros as needed. But either method requires atemOSC. Not using macros would allow me to apply audio fades I believe.

[randallpacker]

Everyone has their workflow and needs. I am a composer and multimedia artist and Max allows me to build musical processes into my performance work. I am triggering ATEM using rhythmic patterns and algorithmic indeterminacy, so it's complex in a different way. Glad there is so much technological diversity in this group... fascinating!!