TCP/Ethernet Automation from Sony SRX-R320/LMT-300

[Marco Giustini]

If memory serves the 750 is supported on the 320 via both ethernet and serial while the 650 is only via serial control. But that was a long time ago.

[Bruce Cloutier]

It baffles me how a product line ends up being so inconsistent model to model so as to eventually cause customers inconvenience. Well, in a large organization I can see how it happens. But this is the kind of thing an emulator/simulator/translator can remedy. The JNIOR is the perfect tool for this. There is a lot of untapped processing power in the units already in your hands. We are also happy to develop on spec. All we have to see is that this supports growth in our user base. All you all have to do is ask for the help. And, help us get it right. We suffer I think for not having experience from our own cinemas. The product being generic.

[Mark Gulbrandsen]

It would be great if someone wrote a program for the Raspberry PI 4 to turn it into a programmable automation. You could have a complete very reliable automation with touch screen for about 200USD.

https://www.youtube.com/watch?v=OQyntQLazMU

[Carsten Kurz]

It baffles me how a product line ends up being so inconsistent model to model so as to eventually cause customers inconvenience.

Oh my Bruce! While the JNIOR went from 3xx to 4xx with some software compatibility issues, too, Sony went one step further from 3xx to 5xx!

Honestly, the Sony R510/515/DS/810/815/DS are certainly a product line, and all share the same software functionality. The R5xx clearly was a completely new product compared to the R320 and you would expect some disruption in functionality leading to improved functionality in the new models. After all, Sony later added a lot more cinema processors to the 5xx software (most of them unknown outside China, though ;-) )

Also, it was always possible to control every common cinema processor using GPOs, as both the R320 and R5xx/8xx offer many integrated GPIO ports. That's how we started when our AP20 wasn't supported over Serial/TCP initially.

As the R320 and R5xx/8xx share the same scientific linux base software/OS, I guess it is quite possible that Sony was able to use the same bidirectional CP750 software module for both servers, and just didn't mention it in the software release notes. But software upgrades for the R320 ended a long time ago.

Agreed that Sony was completely ignorant towards technical communication that went beyond what they decided to put into the documentation. They lost a sale of three machines + a TMS at a cinema nearby because they could not be persuaded to tell the integrator or future owner a way to issue a simple 'Show Start/Pause' command over TCP from an automation system. Their TMS would of course do it, but the buyer needed an external means to perform it - but Sony decided not to communicate and lost the sale.

[Steve Guttag]

Most of our customers have extensive Volume cues...something not easily supported via GPIO. They have more than basic volumes based on show segment. So, any projector that refused to support such things via RS232 or TCP/IP would be disqualified from consideration. It is sort of like the issue I have with the CP850 and CP950 from Dolby. We still use the 8-channel analog input in many places (not all, but enough) so those processors are rejected immediately as incapable of fulfilling the role needed. It just happened again on quote where a film system will remain so we want the analog input for the film system's sound processor to come in...nope, not with the CP950. QSC, Trinnov or even Datasat offer products that meet the needs of the space.

We never used the Sony projectors and the company has always had an arrogant stance of doing things their way or if not invented there. Okay...fade back into the dust like you did with SDDS.

As for using RP with a touchscreen (and relays) for $200...go for it...tell me how it works out. I can certainly appreciate the feeling of freedom of using an RP to do a great many things. They are low cost and if you like to code things, they can be most versatile. But, when you are going to make an automation for market, you should think about long-term support too. If you look at Eprad or Integ, you have products that companies are going to stand behind and there will be documentation of changes and have a legacy product stability. One of the chief reasons I use the Eprad eCNA is that it is rock-stable. Its failure rate is almost non-existent. It also tends to harmonize whatever projector or server happens to be in the booth.

Sort of an equivalent to using an RP as an automation is using a product like Q-SYS as an automation. If one is willing to learn or can code in LUA, making Q-SYS behave as another Cinema Processor is certainly doable. Because Q-SYS could be running multiple screens for sound, one may have to get more creative on how to connect to the various servers thinking that a CP650 or CP750 is what they are talking to. A DSS server is going to talk to a specific port (non-configurable in the DSS) so having one CORE that only has 1 or 2 available NICs talk to many DSS200s could be a challenge without using something like an Ethernet to Serial adapter and bring each DSS in as an RS232 device (program the adapter with the desired TCP/IP and port number. Since every DCIO has an RS232 port, this is possible. There are people already doing Dolby CP knock-off images for Q-SYS. Up to now, they have been to control the CP but there is nothing to stop one from turning that into the UI for a Q-SYS core emulating say a CP650.

[Marco Giustini]

The AP20 automation could actually be used as a translator to fool the 51x projectors thinking they were cp750. Only catch was that it had to happen via rs232. I did the tests myself and it was used for a while until the AP20 was officially supported.

[Carsten Kurz]

Most of our customers have extensive Volume cues...something not easily supported via GPIO.

We used three GPOs to achieve every possible volume. That, of course was only possible practically because the Sony supported Sub-SPLs from the start. So we used one GPO to set our golden average volume, and one + and one - GPO to go everywhere else. The +/- GPO were wired in parallel to our auditorium 'fader'. So at the beginning we used a selection of Volume-Sub-SPLs until full protocol support was possible.

[Steve Guttag]

So, if your features run at say 7.0 and your ADs are down at 4.5, you send a cue that gets it to 7.0 and then 25 minus cues in rapid fire to get it to 4.5? What sort of time frame does it take to move such a quantity?

[Carsten Kurz]

On the AP20, you can also have volumes associated with presets, so it does not have to be a 4.5 base all the time. Also we never felt the need to automate volume in 0.1 increments in that fader curve segment that we use on the AP20.
There is more than enough time, e.g. we have a cinema slide or cellphone policy card that runs long enough to get every GPO cue through. It's not so bad anyway to do it ramping up or down ;-)
It wasn't elegant, but it worked without issues until RAW TCP cues were available.

BTW - the Sony integrated audio processor support protocol allows you to define the specific volume cues you want to have available in the SPL Editor. So you can restrict the SPL Editor volume choices to a useful and manageable range and resolution and not have a long list from 0 to 10 in 0.1 increments. Sometimes Sony DID listen. I guess you just had to buy 100 machines from them for that to happen.

[Steve Guttag]

I have one client that does get down to 0.1 granularity from about 3.0 - 8.0

[Marcel Birgelen]

So, if your features run at say 7.0 and your ADs are down at 4.5, you send a cue that gets it to 7.0 and then 25 minus cues in rapid fire to get it to 4.5? What sort of time frame does it take to move such a quantity?

Well, sending out 0.1 fader deltas in rapid succession to a CP650 is a sure way to kill the TCP interface.

Ideally, you should have a command like "FADE_TO <level> <delay>" to accomplish a smooth fade between levels.

[Carsten Kurz]

Why would one do that to a CP650 if there is a TCP interface? We were talking about GPO pulses when TCP/serial was not supported.

[Marcel Birgelen]

Maybe if you wanted to achieve a "smooth" fade... In our screening room, we're rapid-firing modbus (so essentially serial) commands to some of our dimmers to achieve the same effect.

[Carsten Kurz]

Doesn't the CP650 support fade? I remember the CP500 did. At least a mute-fade.

[Marcel Birgelen]

It has a globally configurable fade-in/out for mute, which also applies for mute commands via TCP/serial. While there must be some ramp-up/ramp-down delay in amplitude-change when setting the fader-level with TCP/serial, this delay is pretty small.