Welcome to the new Film-Tech Forums!
The forum you are looking at is entirely new software. Because there was no good way to import all of the old archived data from the last 20 years on the old software, everyone will need to register for a new account to participate.
To access the original forums from 1999-2019 which are now a "read only" status, click on the "FORUM ARCHIVE" link above.
Please remember registering with your first and last REAL name is mandatory. This forum is for professionals and fake names are not permitted. To get to the registration page click here.
Once the registration has been approved, you will be able to login via the link in the upper right corner of this page.
Also, please remember while it is highly encouraged to upload an avatar image to your profile, is not a requirement. If you choose to upload an avatar image, please remember that it IS a requirement that the image must be a clear photo of your face.
Thank you!
Hello.
Is possible to add JSD60 TCP cues to a DSP100 server? Maybe adding a CP650 with the CONFIG script and modifying some cues file?
If not possible, how can I add serial cues?
It is not possible. You could use a serial to Ethernet adapter to give it Ethernet commands.
Note, later DSS systems (DSS200 or DSS220), in one of the version 4.9 software (not available to the DSS100/DSP100) could have ONE Ethernet device where one could make a suitable XML file with the commands.
Dolby was very closed on their Ethernet usage despite, since the DSS100, its ability to talk Ethernet to the NA10, CP650, CP750.
I can tell you, from my work on a CP650 emulator for Q-SYS, the DSS series really expects the responses to be right or it shuts down the service. For instance, while emulating the CP650 within Q-SYS, I was using an Ethernet to serial adapter so I could present the DSS server with the right port number. If I would push a new design, that would cause the DSS server to see the CP650 stop responding yet the port/socket remained open due to the serial to Ethernet adapter...the DSS would shut down CP650 communication and not recover until the server was rebooted. (My solution was for QSYS to energize a relay when the design was running that then turned on the adapter. So, from the DSS' point of view, it behaved like a CP650...if the unit is off, the socket disappears...if the unit is on, it has a finite time to start responding.
Serial works well. Just experiment a bit with one cue until you get the line terminator correct. I think it's either \0A (line feed) or \0D (carriage return).
If you make the cues "sound" cues they will be available in the GUI otherwise only in a playlist.
If you want to control anything else, serial is a one to one connection so it's all used up with just your JSD60.
I have used a Jnior as a serial to network converter and controlled sound, lights, mag door release, and masking via both the network conversion and relay controls. If you have an NA10, ok it works but is no longer supported at all.
True the recent DSS200 software versions allow network control of non Dolby devices but boy it isn't easy.
I think there is a serial to network manual, the integpg.com website has all the manuals. The Junior app has to be loaded and configured but it works great.
It's pretty straightforward. Firstly, in system > auditorium, you need to enable "this auditorium uses serial automation." If this box is unchecked, the "serial automation" tab disappears.
This example shows the cues for a MiT IMC2-B automation controller, but the principle is the same for any device that can accept cues as regular ASCII strings.
Thank you!!!!
I see that the only way to test the cues is on a playlist.
The SERIAL-TCP conversion of the JSD60 is fantastic. Is an undocumented command? I haven't seen it in the JSD60 manual.
Thanks! I added tcp_send in version 130513 . The manual never caught up. I added this to the JSD-60 when developing the LSS so I could get a DSS-200 to control the LSS. This was before we added the flash sequence script start to the LSS. The string to send can contain any character (including the field separator pipe). The following escape sequences are supported:
\\ = backslash
\t = tab
\n = newline
\r = carriage return
\a is alarm (bell)
\f is form feed
\v is vertical tab
\b is backspace
All of these commands are nice but... The thing is that there are no acknowledgements. So you do not even know for certain that your command was transmitted or received and that the subsequent TCP command was transmitted or received until someone complains that something didn't happen like it should have.
Naturally stuff works great when you test it. Generally it fails when you go to demo it to management. Finally it works as it should until it doesn't and that will be at the worst possible moment.
I realize that the bidirectional aspect implies a protocol and some kind of programming. Then you have to decide what to do if the command fails or the endpoint refuses to do what you ask. These simple strings are easy peasy. I get it.
Then there is the confusion that will occur in a year when the next guy is asked to get it working again and he has no clue.
I shouldn't mention the lack of login or security. This kind of open remote procedure call (RPC) is in part responsible for the hacker's paradise we have created. But.. oh well.. a little too late on that front.
Come on guys... it's 2025 and here we are still discovering escaped characters?
I'm even more grumpy today than usual. Sorry. There is no hope.
Tweet
Comment