开云体育

Howdy,
I am a programming novice, and mostly deal with modifying existing code to add basic functions.
I have been trying to integrate 6 NVX's(NVX350,352, 2 D30s, and 2 E30's) into my complex A/V system(two 3- series processors and a 64x64 and 128x128 dm matrix switchers, and a whole lot of endpoints) using a DIR-160, and am a bit lost on how the programming logic should go.? I've been told that the Director should act more or less like a DM switcher, but I am not sure how the logic with streams should go.? It seems to me that with or without the director, I still need to pull the individual streams into a serial strings for the logic. would I be correct in saying so?
My main goal is to get some hands on experience, as there is an expansion that will be all NVX based, so I want to have a head start on how to use these devices.
Thanks!

On Mon, Mar 31, 2025 at 09:03 AM, <jacksonkfortune@...> wrote:

It seems to me that with or without the director, I still need to pull the individual streams into a serial strings for the logic.

You found the secret.? The XIO Director is a completely useless waste of money.

?

To route NVX Streams, simply provide multicast addresses to your encoders, and put the streamlocation feedbacks of encoders into the streamlocation joins for decoders.? How you decide to accomplish that is up to you.

Wow.? The director cant hold more than one firmware version at a time(I still have NVX's on firmware version 2.x), cant handle credentials effectively, and doesn't even have a useful module to make routing easier?
Now I know why my mentor told me they were useless.? Glad I'm not the one who ordered this.

One caveat - the NVX devices will have to be in the same major revision number as each other for the streams to work.? An encoder on 2.x.x can't steam to a decoder on 5.x.x and so forth.

?

And once an NVX is updated to 5.x or beyond, rolling back the firmware to earlier than 5 will brick it.? Learned that the hard way.

?

Best to just go ahead and get everything on 7 right out of the gate.

Yeah, I had to learn that the hard way.? Now I've got about a dozen NVX's that I'll have to manually iterate up to version 7.x

-beware of multicast switch settings-

?

you can use de firmware updater SW to do the FW install job

?

the director then can be used as a nice paperweight in one IT's Office Desk

?

Oh yeah, DM NVX Tool is the swiss army knife that helps with everything.??

On Mon, Mar 31, 2025 at 12:57 PM, <jacksonkfortune@...> wrote:

you can use de firmware updater SW to do the FW install job

?

I noticed that the firmware updater software is also more reliable than using the director.
Also, luckily my network admins have already prepped my network for the multicast settings.? I probably should've at least asked, as when I was setting it up on my own test bench, my whole LAN froze up due to the multicast packets flooding everything on my little switch.

?

One thing about the DM NVX Tool that's nice is you can do batch firmware updates (as long as the batch is the same model).? So you could use it to "discover" all your 350s, and tell it to push the selected firmware to all of them.? It will chew through them 10 at a time until it gets them all, then notify you if any failed.? Saves LOTS of time at big sites.? ?But yeah you'll still have to step using DM NVX Tool, but it's still way, way faster than doing them one at a time.

If you go to the Files section of this group, and search for "liquidpixel" you'll find our free resources for programming NVX systems. Might be a helpful start for you. It shows you how to handle all the multicast addressing and stream location string routing, and there are several free modules in there that do the heavy lifting (and they have real help files).

?

I'm with the others, as far as the Director not being useful. But just to answer your original question... the Director is programmed similarly to a DM frame switcher, where you can just use analog values to trigger routes. This is done by defining the Director in the devices under an IPID and then attaching all your endpoints inside that (not to their own independent IPIDs). The modules included in the liquidpixel demo program also let you handle routing with analog values, so there's really no advantage to using a Director.

?

--

Josh Winn
The LiquidPixel Group

Use DIR for this - the firmware updates are much easier with DIR compared to using NVX tool.? The new dashboard that was introduced in v4 essentially replaces all of the functions in NVX tool and gives you some that aren't available in NVX Tool.? NVX Tool is not really needed now with the dashboard on DIR.

What are you talking about?? The DIR is like magic.? Who told you they were useless?? You should update firmware on endpoints to current - period.? Don't try to use old firmware on NVX.? DIR DOES handle credentials very well.? Why do you need a module?? DIR is a native Crestron device, not a 3rd party device that would need a module.? There is a programming object, so what's the point of a module?? I think you've been getting some really bad advice from someone who doesn't know how to use a DIR correctly.

Nope, there's absolutely no reason to spend the frankly exorbitant expense of a DIR when you can literally handle every necessary function (besides firmware updates, which are simple enough just with the free DM NVX Tool) from within SIMPL itself.? The only real reason to get a Director is if you need a really expensive machine to bloat a quote's bottom line and insert one more point of failure into the system.? You don't even need to use subscriptions... ADDM (number) (processor address) on the NVX's terminal and if you've written your SIMPL code right, everything just snaps right to where it needs to be.

?

Director's a crutch for people who can't code.

?

?

I would have agreed that Director saves time setting up and updating NVX's originally, but since the release of the NVXTool, most of the needed setup functionality that made the Director worthwhile went away.? For programming, if your under 50 sources (?), then just setup subscriptions and then routing the NVX's streams is the SAME as it is on the director (a single analog value for source stream #).? This is how I've done nearly ALL NVX deployments (using subscriptions).? I've never had a deployment yet that forced me to use serial$ addresses to make the routes, but that wouldn't be much more difficult than analog when/if needed.

?

The downside to the director that I've seen, is when companies engineer systems that have multiple rooms containing NVX and control, and they spec in 1 director for all the NVX's in all the rooms.? That's fine for the setup of them, but for programming and control, it makes no sense to have multiple rooms trying to share a single director so they can do local routing in their local room.? Then you have to architect your programs so that everything for routing funnels down to a single program (single point of failure) that controls the director and EISC's to the other programs.? That is not the best architecture method when you can avoid it (especially for critical functions like routing).? It's much better to have each room directly connect to the NVX endpoints in the local room, and control routing directly, and your programs don't have to be designed to all connect to each other over EISC to handle routing on a single Director.? If the director is used to abstract the NVX's into a DM-type device, it's great...? but most of the time I've seen Director's spec'd into systems, is on larger multi-room deployments where a Director is spec'd in and is expected to handle all the NVX's that span multiple systems, which is not great.

?

But to clarify what the original posted asked, if you use the director or not, you don't HAVE to setup the streaming serial strings if you opt to do the routing using subscriptions.? It takes mere minutes to setup a common list of subscriptions using the NVXTool.

--

Thanks for all of this input.? I ended up using the director for this project, but I think at some point I will probably get rid of it.? When my building expansion occurs, we will be adding a whole bunch more NVX devices and another Processor(probably CP4).? It really sucks that you cant just have multiple processors all controlling the director in one domain.? In some ways, I feel that this is exactly what the director should be good for.? I am wondering if in the future, if I am trying to connect a bunch of independent rooms, If all NVX routing and control should be sent to a single dedicated Crestron Processor with the Director.? Just trying to consider the issue of having endpoints being controlled by multiple processors.
In the end, setting up the subscriptions then just sending serial commands was way easier(and significantly more reliable) than every other thing I tried.? But at least I now am able to have my Extron controller communicate with an RMC3 to control NVX streams.
If y'all are wondering, I just used the generical bidirectional projector rs232 driver in GCP.? It seems the RMC3 isn't picky at all about delimiters from that driver, but the IPCP pro 550 is.