Address Check Behavior

Ouch.  I can't even imagine a reason for it to behave the way it is...

Bug 

The address check function is written to only access intensity parameters (we think of it like a dimmer check).  If the channel has no intensity parameters, it accesses the first parameter of that channel.  We need to make a special case for RGB fixtures to access each of the three outputs. 

That'll be addressed in an upcoming build.

Sorry about that!

a 

Hi Anne,

Not to be difficult, but why?  I think far more often than not, if I'm nexting through addresses, it's troubleshooting either the console's mapping, or a fixture's address setting, not doing a dimmer check.  Its current function seems absolutely wrong to me, but I'd be interested to hear if anyone in the field sees use for the current function.

V 

Hey Victor.... we've argued it every way from Sunday (and back several times).   Like you, we'd be interested to hear input about the feature.  We were trying to come as close as possible to the model of being able to next through your rig to find an unpatched fixture as well.  So, it seems that there are three functions here:

Dimmer Check

Nexting through a saturated rig to find a specific fixture that might not be patched

Troubleshooting a fixture

Perhaps we are overburdening one feature with all of these requirements?

a 

Hello friends....

I would of course love to have an option to next through dimmers in a multiplex environment so that I get a/b addresses in order when troubleshooting. 

My two cents....all is well out here.

Al 

I'd prefer it to be as simple as possible, and not jump around. I would expect Next/Last to go to the next address, not the next intensity. I used to think it was a bug as well.


The multiplexing question is an interesting one, though! I have no opinion whatsoever on that.

All very interesting.   

Jason, yes.  We will treat RGB fixtures as multiple intensity parameters for the purposes of Address next/last.  Probably won't make it into 1.4 (already close to code freeze), but we are planning a "fix it" build 1.4.1.  Will try to get it into that release.

Al (hey!  How are things? Nice to see you - metaphorically speaking).  Dimmer doubling.  Yep, that'd mess with your head.  Is there any time that you wouldn't want the "B" channel to follow the "A" channel in next/last?  

Luke and Victor...  Why do you use address next/last right now and how might that change?  Right now, we don't expose the DMX map to you on multi parameter fixtures.  So, you might need to next/last for that purpose.  In 1.4, About shows you that information.    Address next/last is most commonly used for dimmer checks, is it not?   We also see Address next/last used a lot in a some of our favorite television studios that have a saturated hang.   They use it to quickly identify an unpatched unit needs to be added.    It seems that we might want to optimize Address Next/Last for those behaviors.

If next/last need to access NIPs for palette or preset checks, maybe we would be better served having a different tool specifically for that purpose? Or is there something else in play?  Victor and Luke (and anyone else who wants to chime in) ... thoughts?

Thanks all!

a 

Hi Anne,

When I see addresses brought up and bounced through, it tends to be for either a very simple check of a dimmer rack (or device) or to troubleshoot.  But I think central to both of these is bypassing all of the console's time saving features, because often, one thing I may need to be checking is the console itself, it's mapping, patch, so forth.  Once I have a patch, I have a variety of ways to organize channels.

 I'm slightly baffled by the "next through to find an unpatched fixture" idea.  Unless I'm misunderstanding, it sounds like a bit of a leisurely way to fix a problem. Has someone hidden fixtures in my rig with random addresses?  Perhaps this could be a separate feature, and we could call it "Where's Waldo"?

Al, I'm slightly surprised that it isn't already nexting A to B, I'd certain expect it to behave the way you suggest. 

V
 

Victor:

 I'm slightly baffled by the "next through to find an unpatched fixture" idea.  Unless I'm misunderstanding, it sounds like a bit of a leisurely way to fix a problem. Has someone hidden fixtures in my rig with random addresses?  Perhaps this could be a separate feature, and we could call it "Where's Waldo"?

 

Funny!  This is actually a requirement from the networks, including one of our favs in mid-town Manhattan (and the reason that they are all asking for a return of the ever-popular flash key).     There is a standard hang, but there is not a standard patch.  Hmmm, have never thought to ask why about that, but perhaps it goes back to the days before softpatch....  

 Anyway, they use next/last (often with the flash function) to identify a fixture.  ("I need a 1K fill from over there... those circuits are in the 310 range....find it for me.")

I agree with you.  We are talking about three separate functions here (troubleshooting, identification - aka, where's Waldo - and dimmer check).  Right now, we are trying to use one tool.  

Priority though... of those three, what are you doing the most often?  That'll help.

Thanks!

a 

Hi Anne,

 Ahhhhh.  I get it, we're not talking about fixture versus channel.  We're looking for a conventional which isn't patched, but since we have ML's scattered throughout our dmx range (possibly this is where we should examine our premise, I'd tend to assume more clumping of ML's in patch.) we are making it easier to just hit intensities.

I'd say most often it's troubleshooting, but even if it wasn't, the behavior is too complicated to be the default.  Maybe there could be "intensity address next" to start the...umm....address next filtering.  It seems to me that "by address" is the most primative and raw form of manipulating data, and philosophically should remain unimproved. 

 However...

I also spoke with our esteemed friend from the popular midtown studio, who sees the need for both functions but  prefers the default behavior to skip NP's.  So there you go...I've spoken into a complete circle.

V

Hi Anne,

 Ahhhhh.  I get it, we're not talking about fixture versus channel.  We're looking for a conventional which isn't patched, but since we have ML's scattered throughout our dmx range (possibly this is where we should examine our premise, I'd tend to assume more clumping of ML's in patch.) we are making it easier to just hit intensities.

I'd say most often it's troubleshooting, but even if it wasn't, the behavior is too complicated to be the default.  Maybe there could be "intensity address next" to start the...umm....address next filtering.  It seems to me that "by address" is the most primative and raw form of manipulating data, and philosophically should remain unimproved. 

 However...

I also spoke with our esteemed friend from the popular midtown studio, who sees the need for both functions but  prefers the default behavior to skip NP's.  So there you go...I've spoken into a complete circle.

V