search

bitfocus / companion-module-grassvalley-amp

MIT License
0 stars 1 forks source link

Grass Valley AMP Issue #2

Closed Killerhands closed 5 years ago

Killerhands commented 5 years ago

Trying to use the AMP protocol module and for some reason when I try to send a record command it sends the initial command to connect to open the connection and connect to the right channel but won't send any subsequent messages. I was trying to use it with an ATOMOS Shogun Studio which does work via Dashboard and via our Carbonite AMP connections so I think it may be a bug?

It also seems like when I connect to PacketSender to deubg the issue the initial command to connect to the right channel is missing the padding on the number of characters descriptor. Not sure if that's associated with it at all, but just something I noticed.

haakonnessjoen commented 5 years ago

Hey, thanks for investigating. This module has actually never been tested on any equpment (as far as I know). I have tried to find anyone to do some testing, but have had no luck. I have just written the module "blind", reading manuals. So I would guess the reason it does not send more commands is that it does not get in return what it expects. (I haven't looked at the code for a long time) Could you send me an example of a working conversation from dashboard or similar, so I could look at what the device actually answers, etc?

Killerhands commented 5 years ago

Sure, definitely. Are you on the dev Slack? I can talk to you more on there and describe in more detail. I'm definitely more than willing to walk through with you and square this out.

haakonnessjoen commented 5 years ago

Yes I am :) Look for Håkon Nessjøen

haakonnessjoen commented 5 years ago

Lost you on slack, what was your name again? :P

Killerhands commented 5 years ago

m.ulaky

On Sat, Dec 8, 2018 at 3:11 PM Håkon Nessjøen notifications@github.com wrote:

Lost you on slack, what was your name again? :P

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bitfocus/companion/issues/378#issuecomment-445496924, or mute the thread https://github.com/notifications/unsubscribe-auth/AFXOCVuExZNWPERI57YWNocvm9KVpe10ks5u3EcjgaJpZM4Y6vRO .

danielmerchen commented 5 years ago

Doing a bit of packet sniffing here to see what's going on. When the instance is created for AMP it looks like it tries to send the "heads up a connection is coming" command to the receiving device but doesn't pad the correct number of bytes.

I'm testing using Vtr2 -- as that happens to be my playback channel on this system. It appears all commends are followed by a new line "\n".

What is sent by Companion (1.2 stable): "CRAT7204Vtr2" What works: "CRAT0007204Vtr2"

So the basic syntax is CRAT (which I believe tells it to create a connection) + 4 digit interger (equal to the number of following bytes [204Vtr2 = 7 bytes]) + the actual command.

For channel 1 send: CRAT0007204Vtr1\n For channel 2 send: CRAT0007204Vtr2\n // I don't have a 4 channel unit to test against, but their documentation states the channel just iterates like below. For channel 3 send: CRAT0007204Vtr3\n For channel 4 send: CRAT0007204Vtr4\n

The play action in companion issues a command: "CMDS00042001" -- this is the same string works for me when sending TCP to the AMP device.

When closing a connection with the AMP server it would be nice to do: STOP0000 (for example when disabling an instance.) The GV Documentation makes note that setting up and tearing down connections in unnecessary volume can cause instability or performance issues on the device.

Sending the stop action doesn't result in any packets actually being sent -- seems like something is getting stuck.

Killerhands commented 5 years ago

Hey Daniel, Yes. I experienced the same behavior. Talking with Hakon it looks like the original code was also waiting for a '/n' new line after each response which actually doesn't hold true with responses from the server. He cleaned up the code and fixed the bug and it seems to be working. I'm going to test it when I get back into the studio but Hakon said he was able to have a conversation with ProPresenter without issue with the new code.

On Sun, Dec 9, 2018, 12:56 Daniel Merchen <notifications@github.com wrote:

Doing a bit of packet sniffing here to see what's going on. When the instance is created for AMP it looks like it tries to send the "heads up a connection is coming" command to the receiving device but doesn't pad the correct number of bytes.

I'm testing using Vtr2 -- as that happens to be my playback channel on this system. It appears all commends are followed by a new line "\n".

What is sent by Companion (1.2 stable): "CRAT7204Vtr2" What works: "CRAT0007204Vtr2"

So the basic syntax is CRAT (which I believe tells it to create a connection) + 4 digit interger (equal to the number of following bytes [204Vtr2 = 7 bytes]) + the actual command.

For channel 1 send: CRAT0007204Vtr1\n For channel 2 send: CRAT0007204Vtr2\n // I don't have a 4 channel unit to test against, but their documentation states the channel just iterates like below. For channel 3 send: CRAT0007204Vtr3\n For channel 4 send: CRAT0007204Vtr4\n

The play action in companion issues a command: "CMDS00042001" -- this is the same string works for me when sending TCP to the AMP device.

When closing a connection with the AMP server it would be nice to do: STOP0000 (for example when disabling an instance.) The GV Documentation makes note that setting up and tearing down connections in unnecessary volume can cause instability or performance issues on the device.

Sending the stop action doesn't result in any packets actually being sent -- seems like something is getting stuck.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bitfocus/companion/issues/378#issuecomment-445570953, or mute the thread https://github.com/notifications/unsubscribe-auth/AFXOCZe0ZLDlaf158HqwyBm63ZYCqpD5ks5u3XkNgaJpZM4Y6vRO .

On Dec 9, 2018 12:56, "Daniel Merchen" notifications@github.com wrote:

Doing a bit of packet sniffing here to see what's going on. When the instance is created for AMP it looks like it tries to send the "heads up a connection is coming" command to the receiving device but doesn't pad the correct number of bytes.

I'm testing using Vtr2 -- as that happens to be my playback channel on this system. It appears all commends are followed by a new line "\n".

What is sent by Companion (1.2 stable): "CRAT7204Vtr2" What works: "CRAT0007204Vtr2"

So the basic syntax is CRAT (which I believe tells it to create a connection) + 4 digit interger (equal to the number of following bytes [204Vtr2 = 7 bytes]) + the actual command.

For channel 1 send: CRAT0007204Vtr1\n For channel 2 send: CRAT0007204Vtr2\n // I don't have a 4 channel unit to test against, but their documentation states the channel just iterates like below. For channel 3 send: CRAT0007204Vtr3\n For channel 4 send: CRAT0007204Vtr4\n

The play action in companion issues a command: "CMDS00042001" -- this is the same string works for me when sending TCP to the AMP device.

When closing a connection with the AMP server it would be nice to do: STOP0000 (for example when disabling an instance.) The GV Documentation makes note that setting up and tearing down connections in unnecessary volume can cause instability or performance issues on the device.

Sending the stop action doesn't result in any packets actually being sent -- seems like something is getting stuck.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bitfocus/companion/issues/378#issuecomment-445570953, or mute the thread https://github.com/notifications/unsubscribe-auth/AFXOCZe0ZLDlaf158HqwyBm63ZYCqpD5ks5u3XkNgaJpZM4Y6vRO .

danielmerchen commented 5 years ago

I just tried with da4d677 and noted the connection doesn't set up as noted above (looking a second time, it may simply be stripping the 0's out of the byte count). Perhaps that change hasn't been pushed to the repo yet.

For the sake of documentation, I'm using a Grass Valley K2 Solo 3G.

haakonnessjoen commented 5 years ago

I pushed some changes yesterday, it should be able to send play/stop/load clip. I have also done more work locally to list files. But that is not ready for pushing yet.

Could you please try the latest version. and if it does not work with the K2, I would love if you could send me a wireshark pcap file of the network conversation.

Killerhands commented 5 years ago

Hey Daniel, You should be able to try the latest build now. I was able to test and get connection working with my Shogun Studio record decks.

danielmerchen commented 5 years ago

Awesome -- tried it with the most recent build, Play, Stop, Eject worked flawlessly on K2 using all of the available channels I had ("Vtr1", "Vtr2").

I didn't have any success with load clip when specifying the string/clip name - the dropdown list did populate with available clips but I wasn't able to use it to recall them just yet. I'll have to circle back and give the record function a try.

tonygp22 commented 5 years ago

Any news on getting the record to work?

tonygp22 commented 5 years ago

Nevermind I see it's working now, thank you!

JeffreyDavidsz commented 5 years ago

I didn't have any success with load clip when specifying the string/clip name - the dropdown list did populate with available clips but I wasn't able to use it to recall them just yet. I'll have to circle back and give the record function a try.

What it the status on this? Please file a new issue if needed

emu0117 commented 1 year ago

The LOAD CLIP command is not working properly in T2-4k right now. When I enter the clip name and send the command, nothing happens. The dropdown list only shows "none". PLAY and STOP are working.