Production Switchers

greetings everyone.. I just got my first Ross Video switcher, and am loving it.
I am integrating it into a larger system being controlled via an Extron control processor.

I have encountered something that I've been beating my head against for a half-day, and I honestly can't believe this is the way the product is designed to work.. so therefore I must be missing something.

Behavior Description:

When I want to put Keys #1 and #2 on the preview (and nothing on program), you send the RossTalk command:TRANSINCL ME:1:B:1:2

Then the user can press the "CUT" or "TAKE" buttons I provide.
That executes an "MEAUTO ME:1" or "MECUT ME:1" command.
At this point, the keys disappear from the PV monitor and have been taken to program. Excellent!

The issue I am having is that in this state, the "transition area" buttons now *invert operation* and in order to have Key 1 and Key2 appear back on the preview (while it is on program), I have to send the RossTalk command: TRANSINCL ME:1:B

I can appreciate why this makes sense to a human operator, but what I can't understand is why there isn't a deterministic way to consistently get what I want, regardless of the context of the switcher .. Which RossTalk doesn't *provide* to make matters worse.

I have been experimenting with CustomControls to see if I could find something that would provide the desired functionality, since they can be triggered with RossTalk commands. I have yet to find anything that works in the way that I can identify as useful.

Is there someone out there who can confirm for me that I'm missing something obvious, and send me down the right path? Or am I just doing something that no-one has ever thought of before.. that seems so unlikely to me! It seems like Ross Video through of everything.. except providing even the tiniest of feedback for their "ultra simple protocol", and perhaps the exact thing I want to do right now?

Thank you in advance!
Joel Caturia
Extron EAP

Hi Joel,

For "feedback" we use the OGP (DashBoard Connect) Protocol since then you have access to the paramaters just like DashBoard has....so essentially think of it as the "native API".

For ease of functions and use we made RossTalk so that people could easily fire off commands.

The Behaviour you describe is normal and intended.  You have selected the items you would like and then have performed the transition.  Once done it does not "reset" the transition Area.

However if you would like to have the transition area reset then you can use the "Trans Reset" personality option to do this.  The way after every single transition it will "reset" back to Background and Dissolve mode.

Also this can be done in a custom control as well -- You program it to set the trans area back to BKGD and Dissolve by just taping the BKGD button and then the dissolve button when recording the Custom Control.

Hi Les!

Thank you for your reply. As I said before, these products seem to be so well engineered - I'm certain this is an inexperience/ignorance issue on my part.

I did play with the various personality options that involved transitions, and nothing immediately jumped out at me as I was experimenting with the effects (and reading documentation to explain what they were for).

While "transition reset" did seem promising, it actually doesn't solve the core behavior issue I am trying to work through.
When "transition reset" is set to "reset", the video keys do not disappear from the preview display when they are taken to program (not actually what I want).. and in either case, the effect those keyer buttons have is inverted, even if the state of the button light has been "reset".

Now, let's talk about OGP for a moment. I am already a Dashboard Connect program member, and have access to all of the documentation. I am a bit "underwhelmed" by the documentation, and the support I have been offered up to this point. The documentation appears to be written from the perspective of designing a device that Dashboard can speak to (over OGP), but if you'll permit me to be a bit blunt for a moment .. It doesn't appear Ross Video really wants to support me in speaking OGP to a Carbonite switcher. This is the second or third time I've seen you tell someone on the forums they need to use OGP, so I had every expectation this was a supported activity.

Can you assist me in rallying resources to get my perceptions changed, please?

I would greatly appreciate any assistance you can provide. I'm so excited to have the opportunity to use a Ross Video  product in a project, and continue adding them to my toolbox going forward! I do have an open ticket with support: ticket # 31659

- Joel

Okay so we have two different things here.

One is understanding how a next transition area works....Keyers are layers that "add" to the composite of the output and the next transition is selecting to "change the state" of the keyer.

The BKGD allows you to swap between the BKGD and the PST bus.

PV is the "Output" of the ME that shows you what PGM will look like based on the combinations of selections that are made in the next transition and then current on air state of those.  Thus providing you with a "what you see is what you get".

This is not the same as selecting "what you want" to have independent of what is on air... That sounds more like how a Master Control switcher works where it really has 2 "sides" and you have to re select your composition for the next event.

Now it is also possible to maybe look at using the Memory AI functionality if what you are really after is the concept of "scenes" where you would recall a memory that is using Memory AI and it will "figure" out how to setup the switcher to give you the result that you stored on air...Thus finding other keyers and defining the next trans area to get you to the next "Look" that you are after...

There are plenty of Ross U videos that can explain many of the operational elements of the production switcher:

https://www.rossvideo.com/products-services/acquisition-production/production-switchers/carbonite-black/carbonite-black-u/

and more specifically the Memory AI feature at the 8 min is mark of this one:

https://www.rossvideo.com/gallery/store-recall-memories/

We have plenty of vendors controlling the Carbonite via OGP  -- example is Avid/Orad with their TD Control product and they reached out last week to me to check on it working with the Newer Ultra product and confirm the OIDs that they would be using.....

Ross is not against other vendors controlling our Carbonite Units via OGP.  And yes the majority of interactions does come from those wanting to implement OGP into their devices.

Les:

Thank you again for your reply. I spent the better part of the day implementing the basic OGP protocol in Python, and I'm pleased with my progress.

The burning question of the day now: Is it possible to get a cheat-sheet for the OIDs that I would care about most? I understand you can query devices to get this information in real-time, but since I am not planning on supporting any other device I'm looking to cut the corner.

Finally, I'm interested in talking to my CBF-109 over SNMP. Is it supported on this model? I don't see in the documentation that it is. If I search for "SNMP" in the online documentation I get nothing, other than the MIBs themselves.

Thank you, and have a great day!

- Joel

There is no SNMP in the switchers.  All of the information that is on the Status page are OIDs that you can access in a similar matter for alarming.

OIDs can be inspected using DashBoard and the CTRL+I then you can click on anything to get the OIDs...

There is no Documented List of them as they are implemented with the Binary assignment and not a String OID.

I have it on the list of requests to have as much of this documented as possible...one of the issues is that they can "change" since they don't have to be fixed.