atemOSC
atemOSC copied to clipboard
SteffeyDev
Hyperdeck Control (via TCP)
I've been wondering if it's possible to add hyperdeck control to atemOSC?
I figure that the Studio/Studio mini being controllable over ethernet would make this possible, but perhaps I am wrong.
Would be great to connect to a Hyperdeck and then send it commands from a midi keyboard!
Currently AtemOSC uses the Switcher SDK primarily, with doesn’t work with the HyperDeck as far as I know. However, as you identified, there are documented ways of talking to it over the network, so support is not out of the question.
We would either need a developer with access to a HyperDeck to test on (@blair do you have one?), or you would need to be available to regularly test changes throughout the development.
And of course it is up to @danielbuechele to decide if this is within the scope of the project
I know people who have one, but not any that could do regular testing for us.
Absolutely only if it's in the scope, but I'm definitely voting for it ;)
As for regular testing, I have the TVS HD and HyperDeck Studio Mini here so happy to test throughout if we decide to do it!
How would a integration of Hyperdeck support look like? Does Hyperdeck has it's own SDK we would need to integrate in our app? Before deciding whether we add this or not, I would like to better understand the implications of it. That being said, if any of you is up for integrating this, I am open to this.
HyperDeck devices listen on TCP port 9993 for raw ascii text input, with a set of commands outlined in the user manual (pg. 57): http://documents.blackmagicdesign.com/HyperDeck/HyperDeck_Manual_2015-01-19.pdf
@iamjohnbarker what commands would you be looking to control via midi (e.g. playback speed, video input mode, ...)
So basically we could send strings with the commands to /hyperdeck/sendCommand. The software would just take care of opening the connection.
I assume the api would be something along the lines of /hyperdeck/... or /atem/hyperdeck, and it would be almost a direct mapping of OSC commands to hyperdeck tcp commands.
The protocol is very well documented by BlackMagic, and the only other thing we would need is a new UI for handling connection information with the hyperdeck.
@danielbuechele that would work, personally I would be a bit more in depth and actually build a full wrapper for each command, but any command not wrappped could use that. But as a starting point it would be fairly trivial to just forward the commands as you suggest
This approach allows us to support any kind of commands and not needing to update the software when new commands become available. We can still have "shortcuts" for certain commands.
So what would the UI look like? We just need an IP for the hyperdeck, and a connection indicator showing a green light while connected. Is there anything else we need?
Sorry @blair, I meant @sneat, no auto complete on mobile so I just go for it.
@danielbuechele I think the UI would actually be that simple, so just a subset of what we are currently using.
My only other suggestion would be too look at supporting multiple hyperdecks right off the bat. Easier to build in the support from the beginning rather than retrofitting it in later.
And @blair you got a good github username :)
@SteffeyDev Personally, Record stop/start would be my main uses for it, but building in the function for the buttons on the front (at the very least) would make it useful for other users for sure.
I have four HyperDeck Minis and an ATEM Television Studio HD. Would love to get them talking to each other via OSC. Happy to bang on them with code if would help move this feature forward!
I’m coming at this more from the OSC side of things, unfortunately. At the moment I’m using the Hyperdecks when triggered from TCP via Applescript. I also do a fair amount of OSC in QLab, so my interest in this feature is to unify that process a bit, get the Hyperdecks under OSC control. I’ve dabbled in ASobjC a little & would be happy to do some more — but I’m fairly noob in that regard. ;)
Just noticing this as I'm setting up my rig for an event in a couple of weeks...as we know, ATEM Software Control (7.2) allows you to control up to four HyperDecks from within the application. But the HyperDecks will only allow one client to be connected via TCP at a time, and they even include a "watchdog" function in the deck's firmware to kick that client off after "x" seconds if no further commands are received.
The bad news is that ATEM Software Control appears to be using a TCP session with the HyperDeck to send control commands back and forth, and is "keeping alive" that connection for as long as the two devices are on the same network and the ATEM is configured to control the HyperDeck. This is true whether ATEM Software Control is open or not.
So, scenario: you've configured ATEM Software Control to control your HyperDecks. That means commands can only come from the app; you can no longer send any other TCP commands to the deck; the deck will ignore you and shut down the connection. The only "workaround" is to not connect the HyperDecks to the app at all, and deal with communicating with them separately.
So I would suggest that having atemOSC support control of attached HyperDecks is more than a simple "nice to have." If the user is trying to control the HyperDecks from the ATEM, doing so forecloses the other communication channel with the HyperDeck for other apps.
One more vote for integration of Hyperdeck Mini control into atemOSC (-:
@MarcoCorzani According to @recordandmix, You couldn't use both the app and atemOSC couldn't be connected. Would you be OK just using atemOSC, and not using the app? (disclaimer: I've never used the app, and don't know what functionality it provides)
@SteffeyDev Since controlling the Mini in the app is a real pain I would prefer just using atemOSC. The buttons and switches in the app are way to small to be useful.
@MarcoCorzani @SteffeyDev to clarify, if you have set up ATEM Software Control to control your Hyperdecks, there is no other way to control them besides pushing buttons on the front. And as long as the ATEM and HyperDeck are on the same network, they will maintain an open communications channel between them, whether ATEM Software Control is currently open or not. So the choice is not "atemOSC or ATEM Software Control". Rather, it's "ATEM Software Control or some other method that lets you communicate with your HyperDecks via TCP". If you go down the rabbit hole of letting ATEM Software Control control your HyperDecks, you foreclose any other way of remotely communicating with them.
And it's for that reason that I think atemOSC should support HyperDeck control. If atemOSC is essentially creating OSC hooks to various ATEM Software Control features, being able to support this one (that is, provide another way of controlling the HyperDecks without having to use the admittedly poor UI of the ATEM Software Control app) eliminates the all-or-nothing aspect of controlling your HyperDecks through ATEM Software Control.
Ok, so it appears that it is not actually ATEM Software Control that connects to the hyper decks and maintains the connection, but the switcher itself. That is why the TCP connection stays even when ATEM Software Control is closed.
On the bright side, it looks like if you connect the HyperDeck to the switcher (as it sounds like most are), atemOSC can still control it for free through the Switcher SDK. Seems pretty straight forward to me.
What I need to know now for this is exactly what HyperDeck functionality you guys want atemOSC to expose?
Here's a list of functions the SDK has available, let me know which ones you need @iamjohnbarker @recordandmix @randallpacker. Obviously the more you need, the longer it will take to implement:
- GetId
- GetConnectionStatus
- IsRemoteAccessEnabled
- GetStorageMediaCount
- GetStorageMediaState
- GetActiveStorageMedia / SetActiveStorageMedia
- GetClipCount
- GetSwitcherInput / SetSwitcherInput
- GetFrameRate
- IsInterlacedVideo
- IsDropFrameTimeCode
- GetPlayerState
- GetCurrentClip / SetCurrentClip
- GetCurrentClipTime / SetCurrentClipTime
- GetCurrentTimelineTime / SetCurrentTimelineTime
- GetEstimatedRecordTimeRemaining
- Play
- Record
- Stop
- Shuttle
- GetShuttleSpeed
- Jog
- GetLoopedPlayback / SetLoopedPlayback
- GetSingleClipPlayback / SetSingleClipPlayback
- GetAutoRollOnTake / SetAutoRollOnTake
- GetAutoRollOnTakeFrameDelay / SetAutoRollOnTakeFrameDelay
- GetNetworkAddress / SetNetworkAddress
Greetings Peter.
So happy to see such significant new improvements!! I have been using Macros to control my three Hyperdecks from Max/MSP, but this is an incredibly laborious method, so it would extraordinary to have direct control. Besides all the basic functionality you have already listed, one thing that is not currently controllable as far as I know is cueing up a video at a given time point, not just the start. I guess this is what you are referring to as CurrentClipTime? So be able to play a video from a specific clip time would be great. Also to be able to play a video at any speed, forwards and backwards would be fantastic.
That's all I can think of for now. But thanks so much for all the great work! Randall
It looks like shuttle allows you to change the speed: The Shuttle method starts playback on the connected HyperDeck at the requested speed. I believe you are correct about CurrentClipTime. Not sure how you cue up a video, seems like SetCurrentClip requires you to know the ID of the clip. I've never used a HyperDeck, do you normally set current clip by ID?
To be clear, the methods listed above are those supported by the BlackMagic SDK, not by atemOSC. I could implement any number of those in atemOSC, or all of them if desired. Logic tells me that certain endpoints like Get/SetNetworkAddress don't need to be implemented in OSC though.
Hi Peter,
Thanks for jumping on this! I haven’t looked at the SDK recently, but does BMD not offer the “record clip with name:” command to the ATEM? That’s the biggie for me. I have four decks that I’m controlling via TCP to start and stop recordings of the same event from 4 different angles. I then have to pull them up again on demand, so the file names are pretty critical to my application.
It looks like the SDK does have a list of clips, including the name of the clip and the ID. So atemOSC could grab a list of clips and you could play them back by name or ID. However, I don't see a method of specifying the name of the clip before recording. If ATEM Software Control offers this, can you screenshot or video this functionality so I can better understand what you are talking about?
Ah, I think I found what you are referring to on page 57 of the manual (http://documents.blackmagicdesign.com/HyperDeck/HyperDeck_Manual_2015-01-19.pdf)
yes! That's it. Currently I'm accessing that feature using one-shot netcat (nc) commands sent from the command line. You send record: name: "[clip name]" and you can specify the name the drive will use to write to disk. I'm tagging them as "[scene name]_Cam[XX]", which allows me to recall specific clips as needed. Great as a poor man's instant replay, because if you know the name of the clip when you wrote it, recalling it later is a piece of cake.
Also, I should throw this out there...earlier in the thread Daniel & others mentioned that they were looking for HyperDeck owners who knew a little Obj-C that could bang on code. I still don't really know any Obj-C, but I've been working on a couple of other projects learning Swift...would that skill be helpful on this project at any point?
I can't seem to see an equivalent method in the SDK, but I can email BlackMagic support and see if they have plans to add this anytime soon.