EOS/Nomad: Trapped in Version Skew

[Jay Ashworth]

[ EDIT: Jimmy points out below that ETC *has* built Nomad 2.9.2 for OS/X 64-bit, which means that about 2/3 of this post are no longer an issue... mostly. ]

I have -- I think I have -- a policy disagreement with the EOS department at ETC, and I'd like some eyeballs on it, to tells me which of us is crazy.

I have, in my theatre, 2 or maybe 3 Macs running pre-Catalina OS/X. One of our instructors, the Stagecraft adjunct, has an MBP running Big Sur. He has a license for Nomad.

We have 2 Ion's: a new one running 3.0.3, and an older one (on XPe) running 2.8.3.

He would like, understandably, to be able to tech in a show on his MacBook (in the theatre with the 2.8 board), and he's even willing (if absolutely necessary) to play around with which version of Nomad is installed at any given moment -- since the Nomad and console versions of EOS must, tech support tells me, match exactly down to the point release.

And that leads us to two places:

1) They tell me that the 3.0 Nomad he has installed *will not, full stop* mirror[edit: probably not 'mirror'; see comments] a 2.9(.0) Ion. And yet, he did it all last week; wrote 200 cues remotely from his laptop on the deck at American Stage, whose 2.9.0 is also the older XPe board, to the best of my knowledge and belief.

And why did he have to use the 3.x version of Nomad?

2) ETC Tech Support says that it is a policy decision that they *will not* compile older versions of Nomad for newer versions of OS/X -- which *will not run 32-bit binaries at all*. (If you use Macs, you may have already learned about this, possibly, the hard way). Because of that, 3.0 is the oldest Nomad you can run on Macs which have been upgraded to Catalina or newer; older Nomad programs are 32-bit and won't run on newer OS/Xen.

Our two MacMinis will not be upgrading to Catalina at all, as we have quite a number of older packages that are abandonware, but which still work perfectly and either we do not have the budget to replace them, or we simply cannot, and so we cannot use them to mirror our 2.8.3 Ion, as much as I'd like to.

We *can* mirror our 3.0, but we're not rolling that back to 2.9.2 just for compatibility for others -- I know that's a non-starter and I'm not even going to ask -- and it's also apparently impossible to install multiple versions of Nomad simultaneously on the same machine.

I'm not sure it would work to ask ETC to fix the latter problem, but I have been both a producer of software and a professional user/supporter of it for close to 4 decades, and I don't at all think it's unreasonable to ask ETC to compile the older pre-3.0 versions of Nomad in 64-bit for the 64-bit-only OS's.

Most of that was background I thought necessary; the question at the end is the only thing I really want an answer to (though I'm happy to hear opinions on all the side topics)...

 

[Jay Ashworth]

I should probably note that the policy decision is the best understanding of the TS Guy in question, and might not be a perfect rendering, if indeed someone realized it was a policy decision in the first place.

It should be Anne's decision, but she retired, and I got the name of the gent who replaced her... but I didn't write it down, and have forgotten it. :-}

 

[sashapixie]

I can respond to #1: I think there might be a terminology confusion here. A connected mirror must be in the same version as the console it is connecting to, but it also cannot program. A mirror simply shows you the data that is appearing on the screens of the connected console. Is it possible they simply programmed the 200 cues offline and then saved the show? If that were the case they could load that show file on myriad versions of Eos without issue (though unsupported features would not load). It would simply have to be saved in legacy (.esf or .esf2) format.

 

[Jay Ashworth]

Perhaps "mirror" isn't the right term; I never got it working in our main booth.

Whatever mode the real console and his Nomad were in such that he could sit on the deck and write 200 cues.

And it's *possible*... but it didn't happen here: he was live on the Nomad, writing cues on the Ion that had the DMX interfaces.

 

[starksk]

Hi @Jay Ashworth ,

I don't want to skew the results of your poll so I will hold off on giving you answers for your questions and responses to your comments until your poll closes, but I do have a question about one item that you mentioned: Why is the older console still running version 2.8.3? Is there a particular bug/feature/reason that it has not been upgraded to the latest of the 2.x branch? (Just want to understand the full situation)

 

[Jay Ashworth]

Hi @Jay Ashworth ,

I don't want to skew the results of your poll so I will hold off on giving you answers for your questions and responses to your comments until your poll closes, but I do have a question about one item that you mentioned: Why is the older console still running version 2.8.3? Is there a particular bug/feature/reason that it has not been upgraded to the latest of the 2.x branch? (Just want to understand the full situation)

At the time we handed it down from our Mainstage to our blackbox, 2.8.3 was the latest release; I had heard that it would be the *final* release train for XPe consoles. I didn't know there was a 2.9 until my instructor mentioned it to me -- our new Ion Xe, of course, shipped with 3.0, and is at 3.0.3.

I usually do the major upgrades in the summer doldrums, and in the last 2 of those, I wasn't really in the building because DEADLY_VIRUS, so... ;-)

On the other point, it's just like vaccine trials: when the early data says 90%, you short circuit the trial and deploy. If you have any positive information that contradicts what I've said here, please feel free.

 

[MRW Lights]

a couple of things...

1 - ETC doesn't have the time or interest to lie to you. That doesn't mean that information provided to them may not be entirely accurate or that your situation falls outside the expected normal. Since it wasn't your space or system we can only surmise what may have happened at the other theater, where it magically worked.

2- Anne's replacement is Nick Gonsman. I can personally attest to his qualifications to carry Anne's legacy and while I may not disagree with your policy of not upgrading your equipment.... a policy in your theater does not dictate the policy of a manufacturer. ETC or otherwise. I would love for my old Expression 3 or even the old obsessions that are still running out there to be supported, but alas we are left to wallow in our desert of modern technology.

 

[Jay Ashworth]

I'm not sure, MRW (I can call you MRW, right? ) what, exactly, it is that you think my stance is here, but your response seems to me quite a bit too combative for what it *actually* is.

If I think that it's poor business sense for ETC not to put effort into making their gear as usable as possible in what Tom Clancy called "the fleet" -- where roving Lighting Directors might want to be able to work in multiple spaces without presuming to tell the Master Electricians thereof what to do with their consoles... well, I'm pushing 60, and I've been a professional systems analyst for about 40 of those years -- making judgement calls like that is what I get paid for.

And I do in fact think that. But, like Kirk, I was trying to get some straight replies to the poll before getting into the topic that deeply.

But that's by no means an 'attack' on ETC, and if you were "defending" them from me, I think you're misplacing your energy.

I'm perfectly willing to voice my opinion to Mr Gonsman on my own water, I simply wanted to get a feel for whether anyone else gets bit by the problem on a regular basis.. or if people simply stopped bothering to try to use Nomad for that work, since it's overly difficult to do in an environment where the LD might be in 4-6 different houses in a given month. I'm an A1, but I certainly wouldn't want to have to reinstall QLab every time I walked into a new house.

And, having been a developer for a long time, I have at least a reasonable apprehension for how much extra work it is to maintain the package in the fashion I suggest.

 

[Jay Ashworth]

And I think 'Expression' is a strawman here, by comparison to "it would be useful to end users to build older versions of Nomad for 64-bit-only Macs".

 

[TimMc]

The "other end of a shitty stick" question: why can't Apple stop breaking things by leaving a way for 'legacy' code to run as an app-lette?

 

[almorton]

I guess for the same reason MS no longer support 16 bit thunks - the world moves on, and you have to draw a line somewhere.

 

[RonHebbard]

I guess for the same reason MS no longer support 16 bit thunks - the world moves on, and you have to draw a line somewhere.

Similarly, it's difficult to get your abacus recalibrated &/or adapted from Imperial to Metric.
Toodleoo!
Ron Hebbard

 

[MRW Lights]

I'm not sure, MRW (I can call you MRW, right? ) what, exactly, it is that you think my stance is here, but your response seems to me quite a bit too combative for what it *actually* is.

If I think that it's poor business sense for ETC not to put effort into making their gear as usable as possible in what Tom Clancy called "the fleet" -- where roving Lighting Directors might want to be able to work in multiple spaces without presuming to tell the Master Electricians thereof what to do with their consoles... well, I'm pushing 60, and I've been a professional systems analyst for about 40 of those years -- making judgement calls like that is what I get paid for.

And I do in fact think that. But, like Kirk, I was trying to get some straight replies to the poll before getting into the topic that deeply.

But that's by no means an 'attack' on ETC, and if you were "defending" them from me, I think you're misplacing your energy.

I'm perfectly willing to voice my opinion to Mr Gonsman on my own water, I simply wanted to get a feel for whether anyone else gets bit by the problem on a regular basis.. or if people simply stopped bothering to try to use Nomad for that work, since it's overly difficult to do in an environment where the LD might be in 4-6 different houses in a given month. I'm an A1, but I certainly wouldn't want to have to reinstall QLab every time I walked into a new house.

And, having been a developer for a long time, I have at least a reasonable apprehension for how much extra work it is to maintain the package in the fashion I suggest.

Oh Jay my sincere apologies, not meant to be combative at all. I wouldn't expect you to attack ETC and I have high regards when it comes to your experience. I don't think your experience is questioned here on this forum.

I don't know that ETC doesn't make the effort, but you can only chase the bouncing apple for so long... I expect you would agree that XP was a far more stable platform than windows 7 and beyond and yet ETC was forced to make the change due to a myriad of reasons along the likes of product support, security and features...

Though since we're focusing on Nomad... you're not alone in the grumblings of the community at large. The ETC Nomad and EOS forums have had some topics about learning Nomad as an offline editor or operating Nomad in place of a physical console. So much so that Nick is already leaping ahead with planning a learning stage series for Nomad programming and a Nomad specific manual. Unfortunately, I think the issue would remain in that trying to have multiple versions of the software interacting together would be a Frankenstein of code... the unpredictability of behavior is easier to avoid than to figure out why one version of software did something that wasn't executed in another... sometimes the simplest solution is the best solution. It may not be the easiest, but it might be the best.

 

[Jay Ashworth]

Oh Jay my sincere apologies, not meant to be combative at all. I wouldn't expect you to attack ETC and I have high regards when it comes to your experience. I don't think your experience is questioned here on this forum.

Well thanks; that's pleasant to hear.

I don't know that ETC doesn't make the effort, but you can only chase the bouncing apple for so long... I expect you would agree that XP was a far more stable platform than windows 7 and beyond and yet ETC was forced to make the change due to a myriad of reasons along the likes of product support, security and features..

Well, specifically, they had to do that because XPe was manufacturer-discontinued. And I didn't have a problem with that, and it was merely the luck of the draw that the beginning and end of their hardware upgrade program to ameliorate it fell *inside* my particular facility's CIF timing, such that we couldn't take advantage. But as I note elsewhere, that hardware exchange/upgrade program is a "big" thing, in the context of a corporation's product line management.

The thing I'm suggesting here: rebuild (once) the 2.8 and 2.9 releases of Nomad -- or even just 2.9.2 -- as a 64-bit Mac app, so that LDs *who were good little boys and girls* and upgraded their Macs like Apple told them they should aren't screwed by it, as I think we're going to address in this next graf, seems like a much "smaller" thing:

Though since we're focusing on Nomad... you're not alone in the grumblings of the community at large. The ETC Nomad and EOS forums have had some topics about learning Nomad as an offline editor or operating Nomad in place of a physical console. So much so that Nick is already leaping ahead with planning a learning stage series for Nomad programming and a Nomad specific manual. Unfortunately, I think the issue would remain in that trying to have multiple versions of the software interacting together would be a Frankenstein of code... the unpredictability of behavior is easier to avoid than to figure out why one version of software did something that wasn't executed in another... sometimes the simplest solution is the best solution. It may not be the easiest, but it might be the best.

Couple separate topics there, and I will address them in turn (speaking as someone who's interacted with a buildfarm in the past):

Nomad as an offline editor is fine: as long as you save as a legacy showfile, I am told, any console will load a file from any version of Nomad. As noted, that wasn't what my *particular* LD/instructor was trying to attempt.

Operating Nomad *as* your console, with the DMX puck, *also* not a problem; there's no version match to deal with and you can use any version you want to load (I believe the Nomad license permits that anyway). And that carries no load for ETC either: they have already built and QA'd those older versions for the OS release environments current at the time.

The only problem comes at the intersection of:

• "I want to run Nomad in whatever mode should have been called Mirror, but apparently is not, so I can write cues on my laptop in the house *on the main console by remote*, and not have to pull a 150 foot DMX cable and move the board" and
• "Apple sucks, and made it impossible to run 32 bit binaries on the last 2 releases of the OS" AND
• "ETC says that if you can do that thing with Nomad, your Nomad release has to match to the point level what's on the console" AND
• "it's pretty unlikely in the large that MEs in houses will jack around their console version to match your laptop as a travelling LD"

All four of these things taken together are what cause headaches for Lighting Designers employed by *productions* who are renting the house.

For LDs who are at least willing to reinstall Nomad as necessary to match the house console version, they are -- as I note in the Subject -- trapped in version skew: they *can't* run the older Nomads if they have upgrade their MacBook to the newer OS. So we have to recommend that they *not* upgrade the OS (not the best hygiene to encourage for people who are going to be connecting to your production network) OR that they just don't do the work that way (a massive PITA in many circumstances; see above at 150 ft DMX cable).

Setting up the tech table and moving the board is a half hour for 2 guys in either of my houses, and then you have to strike it again.

Sitting down in a chair with your laptop... much easier. It's a *lot* of cumulative labor across the country in the course of a year.

And the alternative is ETC goes back and rebuilds the 2.9 Nomad for 64-bit *once*.

That, right there, is the compare-and-contrast that drove my poll and background story.

Unlike the XPe hardware upgrade to W7e, that one doesn't seem like it's going to cost ETC thousands or tens of thousands of bucks to pull off; the leverage involved in their investment seems pretty high where the channels meet the road.

 

[almorton]

You can dual boot your console between 3.x and 2.9.x - that's not difficult, Similarly, you can install 2.9.x and 3.0.x side by side on a Windows PC. You can install two versions of 2.X on the same PC, but it does require you to do some manual jiggery-pokery with directories and so on, which might be best left unvisited.

Edit: comments seem to have crossed in the ether.

 

[Jay Ashworth]

You can dual boot your console between 3.x and 2.9.x - that's not difficult, Similarly, you can install 2.9.x and 3.0.x side by side on a Windows PC. You can install two versions of 2.X on the same PC, but it does require you to do some manual jiggery-pokery with directories and so on, which might be best left unvisited.

Edit: comments seem to have crossed in the ether.

I only learned yesterday that the new consoles would boot both versions; I need to look into such things as whether they can see each others show files and such, but that's a nice touch -- though it still does not solve the "I am a travelling LD and the ME doesn't give a *damn* what version I want" problem.

And in this case (and, I suspect, many) the Windows version being more flexible doesn't help all my MacBook using LDs.

I do appreciate the extra details, though.

 

[almorton]

Yeah,it's not ideal. I can see why it's done that way, but that doesn't really help you.

 

[JimmyM]

2.9.2 Is available in 64-bit and is compatible with XPe systems. so the solution is to update the XPe to that version(I verified that it installs on my M1 Mac with macOS 11.3.1 Big Sur.)

See this ETC Forum Thread for info on running multiple versions of the nomad software on a Mac(thanks @mikewoodld for your post 2 years ago)

This seems to resolve the main issue here, unless I am missing something.

Also, depending on the designer they may prefer a real console for programming because of the familiarity of the layout, encoder wheels, faders, ect. the "work" in moving a console might made up in time saved by designer/programmer depending on the scale of the production. Just some food for thought.

 

[Jay Ashworth]

2.9.2 Is available in 64-bit and is compatible with XPe systems. so the solution is to update the XPe to that version(I verified that it installs on my M1 Mac with macOS 11.3.1 Big Sur.)

See this ETC Forum Thread for info on running multiple versions of the nomad software on a Mac(thanks @mikewoodld for your post 2 years ago)

This seems to resolve the main issue here, unless I am missing something.

Also, depending on the designer they may prefer a real console for programming because of the familiarity of the layout, encoder wheels, faders, ect. the "work" in moving a console might made up in time saved by designer/programmer depending on the scale of the production. Just some food for thought.

It sure would. Perhaps my instructor is a doofus. Though I don't think Tech Support realized that the 2.9.2 build of Nomad was 64-bit, which is why *I* didn't. Thanks, Jimmy. (Though it doesn't solve his other problem: one house had 2.9.0 and whether they would upgrade for this is indeed up in the air.)

And this thread was *driven* by an LD who was willing to give up the control surface for the convenience, but I know what you mean; those who aren't can still just pull a DMX cable and spend half an hour moving everything.

 

[almorton]

Man, half an hour is easily enough to get the production desk out of the scene dock, set it up in the aud, move the console and monitors and cable them up, connect the dmx and network ports to the RJ45s in the aud, repatch the patch panel and get it all up and going. And to put it all back again.