DMX address by address patching

I've done several strange patching tricks with ETC gateways. I can't imagine Pathway's would have any trouble doing similar things.

The one caveat is if the system gets re-set then someone has to rebuild the patch, not just use factory defaults. Documentation and Backups!!
 
Different product substitutions has resulted in a fubar addressing scheme rather than the designed one. Has anyone experience with address by address (channel by channel) patching, such as using a Pathway Connectivity node and PathScape software? Reliable and stable?

ETC Nodes and Gateways and I'm certain Pathway, all allow an address to address change other than 1:1.

I wouldn't. I'd only do something different at the console where the end user is likely to have access to see what's going on. I wouldnt be doing a different patch in the nodes.

But console/control dependent of course.
 
I know (of) Pathscape. Is Concert what allows programming ETC nodes?

I have worried about the extra layer, back-up, documentation, etc. The problem has been created by sales reps, and their arrogance, procrastination, and unpreparedness; and substituting a product.

I think the idea of duplicating the patch on the console is an interesting. Maybe do one to one on console with labels, then add a node an patch. Kind of wonder if you had a two-port node for just this subsystem if you could have one port programmed 1:1 and the other crossed.
 
Concert is now ETC's general config tool. It allows backup of config files and software updates and similar fun. Look into Conductor as well. It can automatically backup configs with Concert running on board.

One problem with console patching is when the console is off and the architectural system takes over. I've worked on cases where multiple devices have overlapping addresses, mostly due to architectural fixtures with factory only addressing. :wall::wall::wall:

Some consoles used to be more limited in their output range. That's when input mapping must be applied. Or merging sources like a mini-console at the stage managers panel and an architectural system and a main console. It's a very handy tool.
 
I think that Concert/ETC only allows input patching (Advanced input patch). It sounds like you want output patching, which pathport did support with pathport manager, I have not had the need/desire to figure out how to do it in pathscape yet.

What's to prevent readdressing the fixtures?
 
I think that Concert/ETC only allows input patching (Advanced input patch). It sounds like you want output patching, which pathport did support with pathport manager, I have not had the need/desire to figure out how to do it in pathscape yet.

What's to prevent readdressing the fixtures?
@danTt I'm decades out of date but I suspect some 'lesser God' / down market devices may not be capable of being addressed for the full 512. I recall a few lights and effects marketed to DJ's which could only be addressed from 000 to 128 or 256.
Toodleoo!
Ron Hebbard
 
It took a three page letter to fully document but 120+ houselights, 5 different types, some emergency. Design based on fixtures each with its own DMX driver. Substituted fixtures use remote drivers. Non emergency are EldoLED - 32 drivers in a box a 1u rack unit - set start address and it takes next 32. Emergeny and higher current drivers come in different sizes but can be assigned in blocks of 2 addresses. Actually more complex than that. Design included adresses for each fixture in a logical pattern so users could figure it out. Highlight a special guest, use for a staged performer, lightning, chases, waves - who knows what creative uses someone might come up with. Utterly maddening with the total randomixation that the remote drivers with blocks of addresses.

I could be very unpopular and reject it now - I've been offered that option - but somewhere in the $75k range of product was made and shipped to site so trying to be fair to all sides. Owners best interest is priority but thats not always easy to determine. Its a team effort. If I don't try to make this work and reject it now, I'll get no help later. Plug box mounted wrong - tough nuggies. Lessens not learned in a classroom.
 
Agree with Rob.

As it’s an architectural controller ?, not as likely somebodies going in after to try to re-assign channels/zones to addresses, so go the Pathport route and set it up anyway that makes sense.

My only rub as an operator would be trying to control it with a console where I *think* an address range is “U2/135-XX” or something and it turns out the node changes that.
 
I generally aim for a logical layout whenever possible and can empathize with that being a good design priority. In my space I did take the time to map out all of the houselights (DMX, individually addressed and configurable via RDM) and clean up some mess left behind by the installer. In the end, though, the fader in Paradigm says "House Row 1" so who cares whether the addresses are sequential or not? The end user probably never sees the Paradigm patch (or whatever architectural system is present), and the console patch only has to be done once and included in a rep/starter show file. To me those two methods are the right places to do this. Hiding it away in a Gateway may sound more user friendly at first glance, and you can do your best to document it... but five years from now that's going to get lost or forgotten and then someone has to figure out why the fixtures are addressed one way even though the console is talking to them at a different address. They'll probably get there eventually, but it will add a bit of a headache that could be avoided.
 
I'm a bit conflicted in this scenario. In a road house where you are giving patch to external consoles on a regular I can understand why you'd want addresses to make sense--and in this world I like the idea of a pathport gateway with a custom universe handling the output. In a scenario where you can predefine a template showfile and paradigm programming, I have more trouble identifying the benefits of logical addressing on a regular basis.

My concern would be that the gateway serving as a level of patch will not be immediately apparent to the end user--and even if you provide training now, a few years of turnover later everything is going to be different and confused. As an end user, if I walked into a venue like this I'd want the paperwork that identified both the actual addresses as well as the layer of translation and "logical" addresses to be easily accesible and labeled at the dimmers, the node, and the console.

I think the real quesiton becomes does having logical addresses on fixtures for regular usage by the end user with a level of "magic" in the system make more sense than having arbitrary addresses with straightforward distribution.
 

Users who are viewing this thread

Back