-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SuperSource reports all boxes at default values #9
Comments
Hi kellyzdude, First of all, thanks for your report. :) Your code looks OK, it does seem as you're getting default values as you say. I've been taking a look at the code, searching the keyword: I used the original protocol reverse engineering docs to have a little extra info on the switcher's parameters. Keep in mind I'm no expert in video switchers, in fact I have no experience at all using them. :·O There goes a list of thoughts extracted from reading the code.
Please have a look at the logging section of the docs, more specifically the You want to activate the
You'll have to look for the Something which makes me a little suspicious is the fact of seeing 4
Also, I don't think the library would initialize items from Could it be a problem with your switcher's protocol version? I'm guessing you'll see those If you can't make sense of this part, please capture those verbose logs and send them to me, I'll take a look at them. |
No problem! Thanks for the feedback. I see the _top, I also see _SSC a little further down I see multiple InPr messages: I also see multiple SSBP/SSRC messages, though they indicate errors in the data: Looking at the Socket level: To be honest, I'm not sure what I'm looking at. It does appear to have the extra socket level debug data, but I don't know how to read it. As far as protocol version -- it's possible. To be clear, the four boxes I'm looking at are representing boxes on the SuperSource layout -- the Extreme only has a single SuperSource available, but it presents up to four video sources on the view. I'd like to be able to move those around on the canvas, but ideally I need to first know what the current state is. |
I think I found it! Please bear with me... I'll release a new version with this bug fixed as soon as I can. If you're in a hurry and feel brave about making changes in the library's code, it's just 1 byte (I guess/hope): box = self._getBufEnum(3, 8, self._p.boxes) Change the first parameter from box = self._getBufEnum(0, 8, self._p.boxes) ... and you should be ready to go! If you make this change, please let me know. Otherwise you'll have a new version soon, as I said. |
Besides that... while reading the According to the original protocol description, inside the
The
This makes me think that:
Is the information you see in the table right in any way ? |
Version I won't close the issue yet, still waiting for your response on my last comment :) |
Just got a new pull request that seems to be related with this, looks like good news! 😄 |
Hi there, @kellyzdude ! |
I'm utilizing PyATEMMax in an effort to set SuperSource settings, but I'm also trying to gather the current SuperSource state before making changes.
I have this block of code pulling SuperSource state from my ATEM Mini Extreme ISO:
It gets me this output:
Which 1) does not match the ATEM configuration (boxes 1 and 2 are enabled, both are scaled, and have non-0,0 positions), and 2) looks an awful lot like default values are being output.
Is this a defect in the module, or am I doing something wrong in gathering these details?
I have not yet tried setting SuperSource parameters -- maintaining a cache of what I've told SuperSource to do would be a viable, though not-preferred workaround.
Happy to share any additional debug data if needed, just let me know what I need to provide.
The text was updated successfully, but these errors were encountered: