EOS/Nomad: Trapped in Version Skew

Should ETC compile older versions of Nomad for 64-bit only MacOS?

  • No, but it will cause me to think twice about buying consoles from them

    Votes: 0 0.0%

  • Total voters
    15
  • Poll closed .
Actually, my point was closer to, "Jay, couldn't you solve this problem by buying Nomad for your house, so you can manage compatibility?" Honest question. Why are designers schlepping Nomad around and trying to connect with consoles in all these different houses?
Hi there - Long time lurker, first time poster (and colleague of @Jay Ashworth ) Also - Because, as a roving designer and ME, I take every opportunity to program as much as possible before I ever hit the ground in a given city/venue. It is very much to my advantage to be able to 'schlep' Nomad around, but only in so much as that I can connect up to boards in many different venues. In some cases, the venues could just update their software but, in many cases - as with smaller venues or venues with smaller budgets - the hardware limitations prevent updates.

The point is that the onus should not be on the designer, the venue, or the electrician. The software should be able to absorb minor differences - tbch, I believe it should be backward compatible all the way back to v0.1, but I understand that's asking a lot. At a minimum, fixture libraries and software versions should be backwards compatible at least two full version numbers. It seems churlish at best (on the part of software development) for EOS to require such exact version synchrony. And a pain in my tuchus at least once every gig (eg like - literally - at this exact moment smh).

EDIT - I might add that, as a (pretty much unacceptable) work-around, I generally have two versions of the software on my mac, (2.9.0 and the latest version) but then there's the added layer of breakage that occurs when I have to update my fixture library. That is - I can have multiple versions of the EOS family on my machine, but if I update the fixture library in 3.1.x, it is also updated in 2.9.0!!!!! Which BREAKS 2.9.0 and so even my inadequate work-around is not a solution. AAAAND, EOS makes downloading fixture libraries prior to 2.9.2 (aka 2.9.0) nearly impossible - at least, I have not been able to find them so far...
 

Attachments

  • 20220130_105312.jpg
    20220130_105312.jpg
    392.9 KB · Views: 96
  • Screen Shot 2022-01-30 at 11.56.48 AM.png
    Screen Shot 2022-01-30 at 11.56.48 AM.png
    710.6 KB · Views: 100
  • Screen Shot 2022-01-30 at 11.55.53 AM.png
    Screen Shot 2022-01-30 at 11.55.53 AM.png
    336.1 KB · Views: 109
Last edited:
Okay - so - not to beat a dead horse, but I find that I am completely unable to connect to the eos board at this venue because they are running fixture lib 2.9.0 build 40 and the furthest back I am able to download is build 43, and believe it or not, fixture libraries must be EXACT MATCHES - not full numbers - not one decimal place - not two decimal places, but down to the BUILD!
 
Zeb, it should be noted, was the colleague who's problems in this vein inspired my creation of this thread. :)

Hopefully, his reiteration of his travails illuminates my crystallization of the problem: Roving LDs, probably the biggest target for Nomad, *can't use it*, because we have no control whatever over the software versions which are maintained by house electricians on their desks, and it can be a massive pain in the ass to skew Nomad around on your laptop to match whatever that is, even if you know in advance what it is... and portaging a show file back and forth has it's own set of problems.
 
Okay - so - not to beat a dead horse, but I find that I am completely unable to connect to the eos board at this venue because they are running fixture lib 2.9.0 build 40 and the furthest back I am able to download is build 43, and believe it or not, fixture libraries must be EXACT MATCHES - not full numbers - not one decimal place - not two decimal places, but down to the BUILD!

If the venue upgraded to 2.9.2, then your problems would be solved, no? This seems like a very simple fix. If the venue is unwilling to upgrade the software for some reason, and you're unable to do your job then I'm not sure how anyone can help?

This also seems like the solution to all of your problems: Require venues to upgrade to 2.9.2.

Just to say out loud, MA does not allow you to go backwards with showfiles, so that fact that Eos does allow this was a bit of a brain bender to people when Eos first came out ~15 (!!!) years ago.

I'm sure building new versions of Eos for old versions of macOS software is fraught with pitfalls. I would very much prefer ETC to keep adding new features rather than spending limited time testing new software on old versions of macOS.
 
If the venue upgraded to 2.9.2, then your problems would be solved, no? This seems like a very simple fix. If the venue is unwilling to upgrade the software for some reason, and you're unable to do your job then I'm not sure how anyone can help?

This also seems like the solution to all of your problems: Require venues to upgrade to 2.9.2.
Really?

I try, whenever possible, to be as polite on CB as I can, but:

You're kidding, right?

You think a roving LD, *two* layers removed from the person who has to make the decision, if not three, can "require venues" to do *any little thing at all*?

Do you actually work in this business? For money?

The person who would make that decision is the House Master Electrician or the in-house Lighting Designer, and the odds are slim enough they're going to make an upgrade to their lighting desk at the request of *a rental customer*, much less *the LD hired by* a rental customer -- we're pretty easy to get along with (and we have me), and we probably wouldn't do it.

Thanks, though, for saying out loud the thing other commenters were only kinda suggesting, so that I may scoff at it properly and completely. :)
 
You think a roving LD, *two* layers removed from the person who has to make the decision, if not three, can "require venues" to do *any little thing at all*?
I mean, yes? This is a standard part of a prep and planning process. One of the essential questions my team asks during the preproduction process. “What version software are you on?” I can count on one hand the times I’ve gotten any kind of pushback from a venue, and usually that’s just because someone was operating on a faulty understanding of the upgrade process. I can’t recall having been in a situation where myself or my programmer hasn’t been able to get a console updated appropriately for a show after a conversation and perhaps some education.

It’s 2022, there is absolutely no reason that XP hardware in small, midsize, and large regional theatres shouldn’t be running 2.9.2, Which solves this entire issue. The only exception I can possibly entertain is a venue with a show that has been running for years with no issues - but if you’re doing a show in a venue like that, this also isn’t an issue because you theoretically wouldn’t be doing a new show there.

The person who would make that decision is the House Master Electrician or the in-house Lighting Designer, and the odds are slim enough they're going to make an upgrade to their lighting desk at the request of *a rental customer*, much less *the LD hired by* a rental customer -- we're pretty easy to get along with (and we have me), and we probably wouldn't do it.
I think this is more of a personnel issue and not a software issue. If you have someone running a venue purposely keeping old software running on a console for a non-show specific reason, I think it’s time to have a conversation and training with that person.

I also would have respect for the person coming in making the ask if I were In your shoes in this hypothetical that you’ve laid out. If it was a regular thing, I’d be asking myself what I’m missing in my own knowledge or policies/procedures that is making it a regular occurrence.

Do you actually work in this business? For money?

Scott is one of the most proficient and knowledgeable Eos programmers in this business. Pretty successful, too, if you check out his website or profile.
 
Well it's like this: if I'm renting your venue and you won't upgrade the console software to work with MY designer, you'll hire in the desk I need at no cost to me or upgrade yours. Or I'll advise the producer to renegotiate the deal or move the show to a more professional facility.

You don't work with producers with contract riders, eh, Jay?
 
The software should be able to absorb minor differences - tbch, I believe it should be backward compatible all the way back to v0.1, but I understand that's asking a lot

As someone who writes software for a living I'd say, while in theory that's all possible, having shims and exception code to handle version differences and subtle changes in how functionality behaves is just increasing the bug surface. Often, it's just not worth the extra effort to support an old version at the expense of added complexity for no gain for the vast majority of end users.
 
Well it's like this: if I'm renting your venue and you won't upgrade the console software to work with MY designer, you'll hire in the desk I need at no cost to me or upgrade yours. Or I'll advise the producer to renegotiate the deal or move the show to a more professional facility.

You don't work with producers with contract riders, eh, Jay?
Never. And neither does any other venue in town, except the Big Union Houses, I would speculate.

But everyone's done just a bangup job here of telling me that I don't live in the world I live in, because that world simply doesn't exist, so I'm just gonna go back to living in it, and putting up with the annoyances, and stop trying to convince other people (who are convinced that they don't exist) that they exist.

Y'all have a nice hell week.
 
@mikewoodld for shame lol :) I'm surprisedat your responses - I've definitely got a rebuttal - There's a lot to respond to here, @Jay Ashworth ... but I'm gonna have to look at it properly later today lol
 

Attachments

  • 20220131_130345.jpg
    20220131_130345.jpg
    372.7 KB · Views: 106
So who explains to the *producer and director* that the VENUE is deciding what level of lighting design or programming will be accommodated?

The words I want to use trip the "word nanny" here, but venue rental is a service business and if a venue cannot or will not accommodate the needs of the show, I suggest the producer look elsewhere or find the budget to fix whatever the problem is.

One of my continual rants is about "designers" from various crafts who will design without regard for the ability of a venue to physically stage the production - floor load, counterweight system, available electrical service. In the grand scheme of things a software update to the LX console is trivial money and I work in a craft (and as a vendor) where the expectation of latest firmware is not negotiable.

Jay, sorry if that doesn't comport with your reality.
 
Last edited:
I work in a craft (and as a vendor) where the expectation of latest firmware is not negotiable.
Yeah, I mean it's one thing not to be a new adopter for the latest firmware on the market when you're already in the middle of a production run. It's also excusable if you've got a long term installation like a Vegas or Broadway show that's already programmed and upgrading from a 2.x to 3.x platform is a major risk of unknown consequence for little tangible benefit.

Completely different though to be a roadhouse venue 1) who failed to upgrade their XP console during a program with multiple extensions, and 2) who is resistant to upgrading to the terminal firmware for their console, which has been battle-tested now for over 2 years since it was released.

I'd be remiss not to point out that XP also represents major security risks and in an industry that lives or dies by USB flash drives of unknown provenance getting dragged from venue to coffee shop to venue to PC-at-the-hotel-that-lets-me-print-something-for-tomorrow, venues with XP consoles are living dangerously. Take that from someone whose company suffered a major cybersecurity attack recently -- you don't want to mess around with unnecessary risks.

To that end, also once had a Crestron XP-embedded device installed in a system for a state senate. One day they're doing a network scan and find the Crestron device is throwing a red flag -- it had a virus on it and no amount of factory-defaulting was going to change that. Had to be returned to the mothership a couple times to fully purge the threat out of it so it no longer posed a risk to the state government's network.
 
First off, there is no reason 2.9.0 should be in use in a production environment except in very limited cases, It has been replaced by 2.9.2 which has been released for well over a year now. It takes 30 minutes from downloading a zip to an update being complete. This was the solution I provided back in November, so I am confused why it hasn't been implemented. If the powers that be are preventing this that is another issue outside of this that should be addressed. A designer is who cares about software versions, newer versions have new features that they may expect to have available to them, if the venue for some inane reason prefers an older software the solution would be to downgrade the software after the run of the show, again, outside of special circumstances Eos consoles should always be running the most current version available(I'd agree that waiting a week after release to install wouldn't be a bad issue, but recall that ETC extensively beta tests all versions. I know the 3.0 beta was tested in some very large televised shows, which demonstrates the trust they have in the software.)
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.)

Eos for Broadway and Eos for you are the same, the scale of your venue has nothing to do with what we are saying, rather that the solution is to update, that is what big shows require to prevent this issue, and it can be used to solve this issue.

The point is that the onus should not be on the designer, the venue, or the electrician. The software should be able to absorb minor differences - tbch, I believe it should be backward compatible all the way back to v0.1, but I understand that's asking a lot. At a minimum, fixture libraries and software versions should be backwards compatible at least two full version numbers. It seems churlish at best (on the part of software development) for EOS to require such exact version synchrony. And a pain in my tuchus at least once every gig (eg like - literally - at this exact moment smh).
As someone who writes software for a living I'd say, while in theory that's all possible, having shims and exception code to handle version differences and subtle changes in how functionality behaves is just increasing the bug surface. Often, it's just not worth the extra effort to support an old version at the expense of added complexity for no gain for the vast majority of end users.
Building off this conversation, Eos has one very specific goal on a high level, which is to turn lights on and off reliably. Anything that prevents this from happening is something that should not be part of the software. software that has to account for variances in every software version prior and "adapt" that information between versions is just extraneous to the goal of Eos, and would prevent it from being the reliable software we know.

I know that Nomad can be frustrating at times, but sometimes the easiest thing is to just follow the instructions, step by step, because when they are followed it really is quite flawless.
 
Well, everyone remains fixed on "the constraints which make your situation hard shouldn't pertain", so I guess I'm gonna have to go with "that's fine, sonny, but this here's the fleet".

Thanks all.
 
Well, everyone remains fixed on "the constraints which make your situation hard shouldn't pertain", so I guess I'm gonna have to go with "that's fine, sonny, but this here's the fleet".

Thanks all.
Fleet® is for constipation... :eek:

I wish the answer you want/need was easy and cheap but the lack of those 2 properties means 'it is what it is.' :(

I'm not without sympathy, Jay... but Mr Quixote wants his jousting lance back... - Tim "Sancho Panza" Mc
 
Fleet® is for constipation... :eek:

I wish the answer you want/need was easy and cheap but the lack of those 2 properties means 'it is what it is.' :(

I'm not without sympathy, Jay... but Mr Quixote wants his jousting lance back... - Tim "Sancho Panza" Mc
Sure.

It's just... I'm fine with "you're part of a distinct minority with that problem, and it's small enough we're not gonna fix it".

I'm just not happy with "that's not actually a problem", which is how I parse most of these answers. And clearly isn't true. And I'm hard pressed to believe we got the only 3 roving LDs in the entire United States, in this metro area, y'know?

And I carefully did not capitalize 'fleet' when quoting Mr Clancy. :cool:

And while the local Renn Fest *has* jousting, they've moved it from 3 miles from my house to 25 miles from my house and now to 65 miles from my house; I'm done. Particularly since they moved from Tampa to Dade City *because it was outside the scope of last year's mask mandate in Hillsborough County*. The principal of Mid-America Festivals, the operator of that and 6 other rennfests, has always been something of a capitalist prick, so it didn't really surprise me, but I'm done with it now.
 

Users who are viewing this thread

Back