Film-Tech Forum ARCHIVE: Sound processor pulse automation?

This is topic Sound processor pulse automation? in forum Digital Cinema Forum at Film-Tech Forum ARCHIVE.

To visit this topic, use this URL:
https://ft-forum.com/ft/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic;f=16;t=002549

Posted by Harold Hallikainen (Member # 5405) on 01-14-2016, 08:03 AM:

How much is the pulse automation input on sound processors being used? As I recall, Dolby (pre-Doremi) and Sony servers do not allow for user defined strings over TCP, so pulse automation may be the simplest way to work with these. Is that still the case? What percentage of installations are using pulse automation on sound processors?

Thanks!

Harold

Posted by Carsten Kurz (Member # 5396) on 01-14-2016, 10:35 AM:

Legacy (sorry Steve) Dolby servers allow userdefined strings over RS232, so as long as the non-Dolby CP supports RS232, no issue. Sonys so far only supported a few fixed CPs over RS232 or Ethernet, others as USL or Datasat needed to be talked to through GPO. Fortunately, the Sonys have plenty of GPOs.

A recent software update (1.30.6) enabled TCP raw communication on the SRX-R515/510/DS systems, so, that issue seems to be solved for the current Sony machines. I haven't checked yet wether that new option actually works with USL and Datasat CPs, but am confident it will.

- Carsten

Posted by Gordon McLeod (Member # 33) on 01-14-2016, 10:43 AM:

We use RS232 on all our instalations that support it on older processors it is a pulse contact

Posted by Mark Gulbrandsen (Member # 72) on 01-14-2016, 02:14 PM:

I have a few sites that kept the JS-95's teamed up with a D to A and we do it that way with those. Otherwise it's all been over TCP. TCP has also been very reliable on USL processors in fact just as reliable than direct contact connection method.

Mark

Posted by Steve Guttag (Member # 268) on 01-14-2016, 05:34 PM:

Yes Carsten, they are legacy now...but dammit they were the best and, by far, the most reliable. Anyone want to start a letter writing campaign to bring them back!

Anywho. I'd say better than 95% of our sound processor communication is Ethernet. We took the opportunity, where possible to retire film based processors and put in DCinema ones for a variety of reasons.

On the Dolby server front, the DSS200 can do both RS232 (to one device only...for us, it is the automation) or via a suitable RS232 to Ethernet adapter it could talk to other and it also has a proper GPIO connector. I say proper because it has actual relays to switch the external device.

Other servers we work with also will talk via Ethernet either directly to the sound processor or via the automation (Ethernet) to the sound processor.

We sometimes leave an available RS232 port open in case there is some form of A/V integration needed.

I think another reason we stay away from contact closure is setting volume. Plus, Once you have a network, it is much easier just to put what you have on it. We are to the point, the soundrack gets a switch so the processor, ADA, Blu-Ray player...whatever can join the party. The switch isn't expensive, pulling in new wire, waste of time/money.

Posted by Carsten Kurz (Member # 5396) on 01-15-2016, 06:29 AM:

You would think that Doremis DCP2000/2k4/ShowVault platform should be outphased or renovated more sooner than later as well. I am quite sure a modernized server platform is already in the making. On the other hand, Dolby 'updated' the DSS200 to a DSS220 for worse, so, what should keep them from doing the same to the Doremi line...

Back to CPs: I think there are a lot of installations still based on CP500/CP65 with Doremi AUD2DA or DMA8(+) around, and using GPOs.

I have even seen installers using GPIOs for equipment control when higher level communication means had been available. Some simply seem to prefer hardwired functions, for either robustness, or because they feel uneasy about setting up serial or ethernet connections.

- Carsten

Posted by Sam D. Chavez (Member # 1841) on 01-15-2016, 10:18 AM:

I tend to agree with Carsten on his points.

It's a big world out there and a lot of installers are the old fashioned type and are still on the learning curve.

Posted by Mark Gulbrandsen (Member # 72) on 01-15-2016, 12:40 PM:

Well, sound automation over TCP didn't happen on any wide scale until after series two projectors arrived. So there may be a number of relay contact systems still around. I can only think of two that I deal with. In the beginning of series two many new sound processors took time to appear on a given servers device list although after updates became the norm they did start to appear little by little.

Mark

Posted by Dave Macaulay (Member # 813) on 01-16-2016, 12:58 PM:

I'm not a fan of the Dolby "legacy" servers closed network. Allowing serial automation opens the door a bit but allowing network control of non-Dolby hardware would have been no big problem for them.
Why wait for control libraries to be released? They are not so hard to create, and the official ones tend to either ignore too many useful commands or include extraneous stuff only very rarely used.

Posted by Harold Hallikainen (Member # 5405) on 01-16-2016, 02:04 PM:

I've always thought that automation strings should be user definable instead of counting on the server supplier to keep updating libraries. The organization of these commands in the server raises an interesting question. I know some systems use an XML file. I think an interesting approach (and I don't design these things) is to take advantage of the directory and file structure of the OS. You might do a directory and file structure something like this:

Dolby
CP750
Digital_1.txt
Digital_2.txt
NS.txt
Fader_7.0.txt
CP850
Digital_1.txt
Digital_2.txt
NS.txt
Fader_7.0.txt
USL
JSD-60
Digital_1.txt
Digital_2.txt
NS.txt
Fader_7.0.txt
JSD-100
Digital_1.txt
Digital_2.txt
NS.txt
Fader_7.0.txt

Each txt file would contain a command (or a sequence of commands) that would be interpreted when the cue is hit in the playlist.

Commands could take a structure similar to what the USL LSS-100P uses to send commands to devices:

lss100.sys.tcp_send_string|192.168.7.232|10001|jsd100.sys.fader\t700\r
First argument is IP address, second is port, third is string to send. Escape codes are:
\\ = backslash
\t = tab
\n = newline
\r = carriage return
\a is alarm (bell)
\f is form feed
\v is vertical tab
\b is backspace

These text files are almost the form of a shell script or batch file. The major difference is the use of a pipe delimiter instead of a space delimiter. I like the use of pipe since it allows us to put a space in a command argument without having to deal with quotes, escaping quotes, etc. This does count on strings used in arguments not include a pipe character, but this has not been an issue (yet). I also commonly use tab as a delimiter, but that's hard to read in a text file (is it a tab or several spaces?). As you can see in the example above, I use \t in a string when I need to send a tab.

Anyway, I think automation commands should be totally user definable so you are not dependent on the server supplier updating a library. If the file structure is published, device manufacturers could put automation definition files on their web sites for users to download and import into their servers to avoid typing.

Harold

Posted by Steve Guttag (Member # 268) on 01-16-2016, 03:42 PM:

Dave,

In System 4.9, the Ethernet port finally opens up for automation control! Nobody was a fan of the closed, Dolby product only, Ethernet port. Lord knows, if Dolby made a projector, they wouldn't have recognized Christie, NEC or Barco either but might have had a kludgey way of controlling them.

Harold...I can understand not wanting to provide automation files for every type of processor or update...however, I think it IS a great idea to actually provide, at least, a basic file. Even if the end user wants more features, if there is a basic file for the popular processors, often it is just a matter of modifying the basic file to create the the desired one.

Everyone has a bit of a different way of thinking for the the communications and what you think may be obvious or makes sense may not make sense or be similar to the last thing the installer used. Having a place to start from is a BIG help.

Some companies don't do a good job at detailing their communication protocol either so once this is discovered, it again is handy to have examples. How hard is it for a server company to have a list of known processors? It isn't like you have to keep updating them...just have a set of known working ones for people to start off with. The more work you make it for the installers the less they want to work with a particular product.

I know of a couple of technicians that will dissuade people from using a particular model of amplifier because it can take the better part of 20 minutes to do an update on the amplifier and if your laptop has a newer version of software than the amp you HAVE to do the update. Furthermore, the amp gives the impression that it is dead during the update and that it has failed the update. I bring this up because what you put an installer through...particularly repetitive tasks, when time is so short, can have a BIG impact on satisfaction of the product. And it is amazing how those first impressions can linger. "Yeah...I dislike that ABC server because I had to spend hours figuring out how to get it to talk to the sound system. Whey couldn't they have a file ready to talk to DEF processor? It isn't like they aren't used by a lot of people." Never mind that once they have their XML or whatever file they can use it again and again later...they'll never forget the first impression.

Posted by Marco Giustini (Member # 4544) on 01-16-2016, 03:57 PM:

quote:
In System 4.9, the Ethernet port finally opens up for automation control!

And who is going to use that now that DSS have been discontinued and all existing servers are already in place with some sort of automation - GPIO or RS232?

UNLESS they are going to port the ShowManager on the Doremi servers. That would explain the lack of development on ShowVault and the continue development of ShowManager. Maybe version 5?

Posted by Harold Hallikainen (Member # 5405) on 01-16-2016, 04:04 PM:

Steve, I agree that a library should be supplied. It should be easy for users to add to it.

Thanks!

Harold

Posted by Carsten Kurz (Member # 5396) on 01-16-2016, 06:39 PM:

I recently talked to Harold privately about USL support in Sony servers, and I had the idea that, from the other side, all CPs could have a very basic set of common commands over serial and/or TCP-IP. E.g. a couple of presets, mute on/off, volume in 0.1 increments from 0 to 10.

But, clearly, raw communication is so easy to implement, that it should be mandatory for every server.

And, there really aren't so many CPs around, and I don't expect the number to increase much after the rollout is complete.

- Carsten

Posted by Steve Guttag (Member # 268) on 01-17-2016, 01:34 PM:

You'd think that but even the "volume in 0.1 increments from 0 to 10" has a wrinkle because some companies just HAVE to be different and do a -80 - +10dB fader instead (I have no problem saying, they are absolutely wrong for doing so but they seem to not want to budge off of it, it shows a lack of understanding how the user interface of a fader works in a cinema).

As for who will use the Ethernet control of devices of the DSS line...I have not a clue...yet...I haven't seen the implementation, just heard about it at the last CinemaCon. However, as things change, who knows. I think that the DSS line of servers will outlive most of the others. They are just that reliable. I know we plan to support them until they are truly unsupportable. But definitely, it is a feature that is YEARS too late.