Barco Communicator Mac, EOL, will not work on latest OS, Workaround?

[James Gardiner]

I support an Audio post house, we are doing a major upgrade, moving all mixing rooms to a newer certified version, ProTools etc.
One issue we have is the Mac Communicator software would refust to connect to DP2K-10SLP. We had to move it to the Dolby Renderer as its running on a old Intel Mac. (Then VNC into it). Not ideal.
I had a resonable look into tryng to figure out if it was still possible to make it work. But ran out of time.
I just wanted to know if others have seen this issue and if there is a work around?

[Frank Cox]

Oracle Virtualbox?

[Harold Hallikainen]

Do web UIs go out of date like this, or do they just keep working with client computer updates? Also, a web UI is platform independent.

On one OEM product we developed at USL, we did a web UI that also served as the front panel UI. The front panel just ran a web browser. The UI code only had to be written once.

Similarly, the IRC emitter panel has a command interpreter. On boot up, all the configuration (which is text saved in flash memory) is sent through the command interpreter. The TCP interface uses the same command interpreter. The web UI sends user input and button presses as commands through a POST request. These are then run through the same command interpreter as everything else. I really like writing code once and using it everywhere.

[Frank Cox]

Do web UIs go out of date like this, or do they just keep working with client computer updates? Also, a web UI is platform independent.

That depends on how the web ui was written. Yesterday's javascript won't necessarily run on today's web browser.

See https://developer.mozilla.org/en-US/...olete_features for a few examples of javascript functions that have been declared to be obsolete and no longer work with a modern web browser.

On the other hand, if the front end is composed of basic html and doesn't require any fancy conga dancing to run, then it should be reasonably future-proof. But then it might not be as pretty and that's where you run into issues....

[Steve Guttag]

I have not seen this problem and just checked that 5.16.6 opens and runs on my Mac (MacMini) running Tahoe. The latest OS is Golden Gate (27). That is supposed to be the last OS for Mac that will support Intel based apps.

I'll admit, in the field, I run with a Windows PC as that has the best application compatibility. At home, I emulate the PC via Parallels.

It will be what comes after Golden Gate (in late 2027 that you would need to be concerned or, if Barco is so inclined, will make an ARM based version. Mac is a big enough user base that it would make sense for them to do it...probably without them hand tweaking anything and just letting the compiler make the version...for better or worse. I think that is all they do for the Mac and Linux versions. It is clear (to me) that the Windows version is the one that they really code for.

[Leo Enticknap]

To be clear, we're not talking about a web UI in this case. Barco Communicator is an app that is used to control all Barco projectors pre-Series 4. Series 4 Barcos use a web UI exclusively: the Communicator app will not talk to them.

Series 2 and 3 ("Series 3" for Barco means Series 2 but with a laser phosphor system replacing the xenon lamphouse and power supplies) Barcos that have the later (post-2018 roughly) variant of the cinemacontroller board also include a "Communicator Lite" web UI that can handle basic operational functions, diagnostics, and lamp swapouts; but even if you have this, you still need the Communicator app for installation and service functions (e.g. color calibration and firmware updates).

One issue we have is the Mac Communicator software would refust to connect to DP2K-10SLP. We had to move it to the Dolby Renderer as its running on a old Intel Mac. (Then VNC into it). Not ideal.

If the app will start up without throwing any errors apart from not being able to communicate with the projector, and if another Mac connected to the same switch will, this suggests to me that the problem is in that computer, not the app per se. Does it have an internal firewall that is blocking the communication port (43728)?

As for the Communicator app, agreed completely with Steve that Windows is clearly the native version, and that the others are likely crude recompilations with little finessing. I detest MacOS and it'll be snowing in Hell before I touch any Mac for a second longer than I absolutely have to, but I use Ubuntu all the time and have done since the early '00s. I've found that the Linux version of Communicator is difficult and fiddly to install, often requiring the manual installation of dependencies first, and that the Windows version running under WINE is an order of magnitude easier to install and more reliable to use.

[Marco Giustini]

I had the same problem the other day for the first time. I could see and connect to the Barco UI but communicator wouldn't connect.

I rebooted, reinstalled, toggled the LAN permissions: nothing worked.

Solution: run it from terminal and it works. I am on Tahoe, I feel 26.7 broke it as it was working before. Not sure if Barco/Apple would fix it as it's an old intel app.
Looking into macOS logs, it was macOS preventing the Communicator from accessing the LAN even though Communicator was authorized to access the LAN. Apparently it's a known issue where macOS can get stuck on blocking an app despite what the UI says AND the communicator being poorly ID'd so macOS cannot handle the permission very well.

27.2 is apparently allowing users to REMOVE and ADD again an app under "Allow LAN access" so that might be able to fix the broken permission but I do not know.

[James Gardiner]

First of all, I don't expect Barco to do anything about this issue, and I agree that, at some point, they have to move on from supporting older tools like this.

I did discuss it with them, and apparently the newer web-based implementation simply wouldn't fit within the limited resources of the older projectors.

As for what we tried, we tested the application on about three different Macs. In each case, the application would launch, but when attempting to connect, we'd get the spinning beachball for about 10 seconds, and then nothing. It would simply return to its previous state, as though the Connect button had never been clicked.

I tested the same connection using a PC, and it worked perfectly. So we knew the problem was Mac-related, or at least related to the particular Macs we were testing. I eventually installed it on an older Intel Mac, and everything worked fine.

Initially, I suspected some sort of macOS security restriction, but after spending about 10 minutes checking, everything appeared to be open. There was no obvious reason for it to fail.

My understanding is that the application is essentially a Java wrapper, so who knows what's happening under the hood? Perhaps newer versions of macOS have introduced security restrictions that affect older Java applications. Understandable, really, given that Java has historically been a bit of a buggy mess!

Normally, this wouldn't be much of an issue, as most cinemas have PCs available. But in an audio post-production house, it's Macs everywhere. Not a PC in sight!

So, ultimately, this isn't really a significant problem for exhibition.

But yes, Harold, the web browser is the way forward.

I remember giving Barco, Dolby and just about everyone else a piece of my mind in the early days when they were all developing their own proprietary native applications. It made supporting these systems unnecessarily complicated.

Look at where we are now. Virtually all the major exhibition tools are web-based, and for good reason. It makes remote support, compatibility and troubleshooting so much easier. We've come a long way!

That brings me to another interesting question: the Barco ICMP-XS.

With this architecture, the player, projector and even the sound processor (if enabled) are all effectively managed through a single IP address and interface.

Should these really be separate?

My instinct says yes, although perhaps that's just my old-school thinking and a preference for keeping things the way they've traditionally been.

I've always preferred treating the projector, media player and sound processor as separate devices or functions. It provides a clearer separation of responsibilities and makes it easier to isolate faults when troubleshooting.

There's something reassuring about being able to identify exactly which component you're talking to, rather than having everything bundled together behind one interface.

Of course, I can see the advantages of integration, particularly for installation and simplified operation. But from a service and troubleshooting perspective, I still wonder whether we've sacrificed some useful separation in the process.

Perhaps I'm just showing my age!

[Harold Hallikainen]

With this architecture, the player, projector and even the sound processor (if enabled) are all effectively managed through a single IP address and interface.

Should these really be separate?

My instinct says yes, although perhaps that's just my old-school thinking and a preference for keeping things the way they've traditionally been.

I've always preferred treating the projector, media player and sound processor as separate devices or functions. It provides a clearer separation of responsibilities and makes it easier to isolate faults when troubleshooting.

There's something reassuring about being able to identify exactly which component you're talking to, rather than having everything bundled together behind one interface.

Of course, I can see the advantages of integration, particularly for installation and simplified operation. But from a service and troubleshooting perspective, I still wonder whether we've sacrificed some useful separation in the process.

I don't really see a need for separate IP addresses for these functions. They may all be running on the same multicore CPU. But, on the UI, it's probably nice to put the separate functions on separate web pages to keep stuff organized. Back in the 1980s, I designed control systems for broadcast transmitters. This was all done using ASCII terminals with block graphics for the UI. The "home" screen would show all the transmitter sites and the status of each. You could then select a site to get a block diagram of the site with the status of each piece of equipment. You could then select a piece of equipment to get all the telemetry out of it and to adjust it. I think this "drill down" approach is fairly intuitive. Now with web interfaces and stuff like QSYS, it's much easier to make much more complex but intuitive UIs. But, I don't think we need to waste IP addresses to separate the functionality (though we may have media and control IP addresses on different hardware ports to separate out high speed and low speed data).

[Steve Guttag]

James, I tend to agree, that convolving three distinct entities into one device, one IP is not, necessarily, the best move. For one, they, inherently, have three different life-cycles. A cinema processor, typically, has a multi-decade life span. There are JSD-80, CP650s, JS-280, CP65...you name it...still showing commercial movies (via a D-A converter, naturally). The CP750 should have had a longer life but its internal power supply (which I think is really the cause of the MB failures) has caused it to have a premature shortened life.

Furthermore, I don't see what the advantage is on convolving the sound processor into the server. If we are in an AES67 world, it is one Ethernet cable. If we are in an AES3 world, it is up to two Ethernet cables. If we are dealing with analog, then you have to deal with D-A converters. And...who say any of the server people are great at sound processors? I'd rather pick my sound system for its feature set as well as serviceability.

The ONLY except I've made to this rule has been for Dolby Atmos. I do use the IMS3000 with Atmos, whenever possible. There, it makes sense. It reduces the KDMs to 1. All of the BS of getting the server and the CP950A to sync up and not have issues are immediately solved. The only down sides I've found are:

• The IMS3000 is not my favorite server.
• The IMS3000 HAS to the GM PTP clock in an AES67 system (e.g. Q-SYS).
• Dolby's weak AES67 implementation requires one to coddle it (don't you dare activate IGMP or you'll lose the AES67 stream since the IMS3000 won't respond.

I only quasi use the IMS3000 as an Atmos sound processor. It immediately hands off the AES67 stream to Q-SYS for real speaker processing...plus all of the control goodness that Q-SYS brings.

Servers, in my opinion, are the shortest of life-cycles. Originally, they were to be 5-7 years and 10-years on the outside. We're seeing more like 10-15 years. But I think that is a happy circumstance rather than an intrinsic design. In the last two years, I've seen our "box server system really diminish as a mediablock (the death knell for any server) fails. Be it a CAT862, CAT745, Dolphin, "IMB" or GDCs IMBs/internal mediablocks. They've just run their course and I think they did quite well. We only had one or two that barely made it over the 5-year mark. I don't think that the sound system should, inherently, be tied to the server. I'm also non-plused that they are being tied to some projectors too (and defacto tied to some).

And then there are the projectors. They are, in my opinion, inherently longer lived than the serves. Original estimates were 10-15 years (or about double that of the servers) but we are seeing 20+ years on some of the projectors. The Christie CP2000S/SB will probably outlive everyone. I still have Barco and Christie S1s in the field...not many but I never had many of them. No more DP100s, thankfully. I have handful of DP2000s out there and some Christie (CP2000SB and CP2000ZX).

So yeah, I think all three should be treated as separate entities where exhibitors can choose what product to use based on their use-case, feature set and demonstrated reliability and support.

[Harold Hallikainen]

Very good points! But hardware costs money. The USL/QSC CMS-5000 (which almost went into production) had, as I recall, a quad core ARM processor. It handled the server functions (SSD access), user interface, IAB rendering to 64 channels, forensic marking of 64 channels, decryption of the audio, and sent the image data to an FPGA for decryption and JPEG decoding. If this can all be done with one CPU, why pay for multiple CPUs, each in their own box with power supplies, I/O, etc.?

[Steve Guttag]

Harold,
The software implementation of an audio processor benefits the manufacturer since while it costs them no more for hardware, they feel obligated to charge for turning the various audio features on. So, from an exhibitor's standpoint, a CP950 or OV2, you actually get something for your money. And, furthermore, when the server's (relatively) short life-cycle concludes, you don't need to re-purchase a sound processor that is working just fine for the theatre.

Even with the software implementation of the sound processor within the sever, as said above, who is to say that the server manufacturer is a good designer of sound processors? The server is already going to output 16-channels of AES3 audio by convention (DCI requirement, I believe). There are few, if any, downsides to an external sound processor. There is a possible cost advantage to having the sound processor in the server but that is dependent on just how much the SERVER MANUFACTURE values that feature and charges for it. Tell me, which do you feel like you got more for your money? $2,000 for a software activation, tied to a server or $3,000 for a hardware solution that covers everything in the software but also adds analog inputs and likely has a life-cycle 2-3 times that of the software...which likely will need to be repurchased 2-3 times?

I've also found that the software implementation of speaker voicing amongst the various manufacturers to be wanting and very pedestrian. So, they aren't the best examples of sound processors either.

What they are really selling is this notion of a fast installation at a slightly cheaper cost. If you are Dolby, you buy your IMS3000 with the sound processing, connect a single CAT cable up to your DMA amplifiers and...ta-da...done. Note, the DMA amplifier has speaker voicing capabilities that exceed the IMS since one can voice subwoofers and surrounds too. Barco and GDC have similar attempted integrations.

But really, okay...if you have a separate sound processor (pick one)...what is the real added installation? A CP950 could also connect to the DMA amplifier with the only added installation work being two CAT cables for AES3 audio into the CP950...a value around $5.00 and a minute's time. Where are the big installation savings? And, not to harp on it too much. Which do do you think will need changing first? The CP950 or the IMS3000? Mind you, I don't want to be picking on Dolby. I could change that to GDC or Barco and make the same arguments against other sound processors, like the OV2. And, furthermore, the exhibitor gets to pick the sound processing that fits their needs rather than being tied to what the server supports.

I think the cost advantages of the sound processor in the server are dubious that become an added expense on each repurchase on server swaps.

Again, the exception I make are on IAB type formats (I used Dolby Atmos above as that is THE format I've used and, in my opinion, the most logical one as it is well-developed rather than the wild-west of DTS-X or other me-too IAB things). Rendering the IAB audio into AES67 (or Dante) streams (flows) in the server makes sense the same way taking the basic 16-channels into AES3 for subsequent processing makes sense as it makes the system less cumbersome (single KDM, no multiple integration signals/cables). I will acknowledge that you run into similar re-purchasing licenses based on server life though I would hope that Dolby would allow the Atmos license to transfer from hardware-to-hardware in the same theatre/screen given that each Atmos system is individually registered with them. As software, that sort of transfer is possible. If the hardware Atmos renderer of a CP950A would require repurchase as one changes the hardware (e.g. if one has a CP850 fail and updates to CP950A though I would hope the actual feature license would transfer). I have no idea how the other entities handle generic IAB where one is having generic IAB in a theatre. DTS-X has some degree of registering but it is still far less-well defined as a system in terms of layout and final result.

[Marco Giustini]

First of all, I don't expect Barco to do anything about this issue, and I agree that, at some point, they have to move on from supporting older tools like this.

Why not, the latest communicator version is from end of 2025. the issue we are experiencing is probably something that can be easily fixed on their end, based on latest Apple's guidelines.

Correct me if I am not mistaken, you need the Communicator to do advanced alignments on a DP2K, correct? The WebUI is only for selecting formats, lamp, dowser etc.
Yes I can run Communicator in a Windows VM but I liked the idea of having a dedicated app!