|
|
 
|
|
Author
|
Topic: Sound processor pulse automation?
|
|
|
|
|
|
|
|
|
Steve Guttag
We forgot the crackers Gromit!!!
Posts: 12814
From: Annapolis, MD
Registered: Dec 1999
|
posted 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.
| IP: Logged
|
|
|
|
|
|
|
|
|
|
Harold Hallikainen
Jedi Master Film Handler
Posts: 906
From: Denver, CO, USA
Registered: Aug 2009
|
posted 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
| IP: Logged
|
|
Steve Guttag
We forgot the crackers Gromit!!!
Posts: 12814
From: Annapolis, MD
Registered: Dec 1999
|
posted 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.
| IP: Logged
|
|
|
|
|
|
Carsten Kurz
Film God
Posts: 4340
From: Cologne, NRW, Germany
Registered: Aug 2009
|
posted 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
| IP: Logged
|
|
|
|
|
|
All times are Central (GMT -6:00)
|
|
Powered by Infopop Corporation
UBB.classicTM
6.3.1.2
The Film-Tech Forums are designed for various members related to the cinema industry to express their opinions, viewpoints and testimonials on various products, services and events based upon speculation, personal knowledge and factual information through use, therefore all views represented here allow no liability upon the publishers of this web site and the owners of said views assume no liability for any ill will resulting from these postings. The posts made here are for educational as well as entertainment purposes and as such anyone viewing this portion of the website must accept these views as statements of the author of that opinion
and agrees to release the authors from any and all liability.
|
Home
Printer-friendly view of this topic