EOS/Nomad: Trapped in Version Skew

[RonHebbard]

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.

Imperial or Metric minutes?
Toodleoo!
Ron Hebbard

 

[Jay Ashworth]

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.

Yup; that's what I said.

And it's a *lot* more time than "walk out to a seat, put down your music stand, open your laptop; write cues".

 

[TimMc]

Yup; that's what I said.

And it's a *lot* more time than "walk out to a seat, put down your music stand, open your laptop; write cues".

In either soft-seater at the local PAC, just getting the tech tables into the house is 30 minutes. Another half hour for LX, audio and props to do their work. An hour each way, for 4 people... call it $200-$300.

Edit ps: when you look at it this way, there becomes a financial incentive for folks to PAY ETC to do this dev work. Seriously, there will be lots of folks get PO'd becasue they'd have to pay, but if it saves money over the next 2 or 3 years, you're likely ahead in financial productivity. I presume Jay's situation is not exclusive to his venue so the question becomes "how many seat licenses (and at what price) will it take ETC to recoup redevelopment costs and loss of programmer time on other projects?"

 

[almorton]

Yup; that's what I said.

And it's a *lot* more time than "walk out to a seat, put down your music stand, open your laptop; write cues".

Sorry, I thought you meant half an hour to set up, another to strike.

 

[Jay Ashworth]

Sorry, I thought you meant half an hour to set up, another to strike.

I did mean that. Both set and strike involve tearing the entire lighting desk apart and setting everything back up at the other end, and either setting or striking the table; ours is a full 4x8', and weighs enough that it's a bitca for two guys to handle. Two guys, 30 minutes, each way. Two manhours vs "just walk out, sit down, and open your laptop."

 

[Jay Ashworth]

Edit ps: when you look at it this way, there becomes a financial incentive for folks to PAY ETC to do this dev work. Seriously, there will be lots of folks get PO'd becasue they'd have to pay, but if it saves money over the next 2 or 3 years, you're likely ahead in financial productivity. I presume Jay's situation is not exclusive to his venue so the question becomes "how many seat licenses (and at what price) will it take ETC to recoup redevelopment costs and loss of programmer time on other projects?"

I don't disagree, but on the other side, ETC already prices tech support into the cost of the boards, and not particularly conservatively, either.

 

[Jay Ashworth]

Well, looking at the results, I see it's just me.

That's ok, I'm used to everyone thinking I'm wrong; it's what I get paid for.

 

[almorton]

I did mean that. Both set and strike involve tearing the entire lighting desk apart and setting everything back up at the other end, and either setting or striking the table; ours is a full 4x8', and weighs enough that it's a bitca for two guys to handle. Two guys, 30 minutes, each way. Two manhours vs "just walk out, sit down, and open your laptop."

Fair enough. Our tech table is nearly 8x4 but it's light, braced and sits on the seating in the aud itself. My timings were for me working alone, shifting an Ion with 2x20 wing attached and two monitors. We have a complete set of cables (3 power, 2 xlr5-RJ45, 1 network cable, 2 video cables) all bagged together so the cabling in the control room can stay in place, just grab the "tech bag" and you're set. Little short cuts that save so much time.

I do feel for you. I did a show in a different theatre where shifting the desk was such a rigmarole you thought they'd never done it before.

Our old strand was even quicker. The keyboard was on a CANBus which ran over cat 5, the display just needed a laptop and dongle to mirror. Took minutes to move the whole shebang.

 

[kicknargel]

Sooo. . . dipping my toe here in a topic that I'm out-of-date on. I'm wondering whether ETC sees Nomad as something that would be owned by the house. Like the wired remote of "my day." So you keep your own gear compatible. Are there unforeseen circumstances that have created a world where the house owns the console but the designer owns the remote device - in this case Nomad software and the hardware it runs on?

 

[Jay Ashworth]

I think the former is certainly possible, though we haven't really heard a policy answer here from ETC, I don't think.

On the latter, I don't think they were all that unforeseen, myself.

 

[starksk]

Now that your poll has closed, here are the answers I was holding back:

1. You cannot mirror nor be a client to a console running a different version of software than you are. In addition, your fixture library version, keyboard and help languages must all be in sync as well for a client to connect to the primary. Running version 2.x and Version 3.x will definitely not connect properly (if at all) to each other. It is possible to program a show offline and save it in formats that are compatible with each other in either branch. Obviously, features that did not exist would not be available in the older versions.

2. As you've discovered, the primary development effort for 2.9.x was indeed to create 64-bit versions of the software to comply with Apple's mandate that apps change to 64-bit. We got most of it right in 2.9.0 but had a couple of bugs near the end of 2.9.0 that caused Catalina support (where Apple does a process notarization) to be delayed until 2.9.1. Eos is not just a single executable and has many utilities and other processes it relies upon for different functions. All of these must also be 64-bit to pass notarization and it turns out that even just recompiling old code with a new compiler can introduce several new behaviours (bugs, features, featured bugs, etc). These things all take time and test effort to ensure that we haven't broken working features just to go to 64-bit. It is just not possible to go back to older code branches and "recompile" as a 64-bit application and expect everything to work due to the complex interactions of the software.

It seems that all of the modern OS developers have an interest in deprecating support for legacy code be it for sales, vulnerability, and/or support reasons. If you were to time capsule your computer, it would run at whatever versions you had at the time, but you couldn't take advantage of new features. If you had upgraded to take advantage of new features, you might also have to upgrade to the appropriate hardware that supports those features as well. This appears to be the trade-off of the world we now live in.

It sounds like you may have been misinformed about software releases and were unaware of newer development. 2.9.2 is the current software version of the 2.9 branch. While we are not planning any further feature releases for the 2.9 branch, we do release fixture library updates to support newer fixtures on older consoles as well as may release critical bug fix versions in that branch in the future. New and exciting feature development will occur in the 3.x branch.

I hope that helps.

 

[starksk]

Sooo. . . dipping my toe here in a topic that I'm out-of-date on. I'm wondering whether ETC sees Nomad as something that would be owned by the house. Like the wired remote of "my day." So you keep your own gear compatible. Are there unforeseen circumstances that have created a world where the house owns the console but the designer owns the remote device - in this case Nomad software and the hardware it runs on?

ETCnomad is not limited in our view as to who owns it. It is obviously easier to manage the dependencies when all of the gear is controlled by one entity, but with communication about the hardware availability and compatibility, desired features included in specific software releases, and local policies for changing versions of equipment, many users are able to successfully work together to create the show they desire.

 

[Jay Ashworth]

ETCnomad is not limited in our view as to who owns it. It is obviously easier to manage the dependencies when all of the gear is controlled by one entity, but with communication about the hardware availability and compatibility, desired features included in specific software releases, and local policies for changing versions of equipment, many users are able to successfully work together to create the show they desire.

I think the thrust of Nick's speculation was more "perhaps, Jay, the limitations that you see in the current ecosystem are due to ETC not having its view zoomed back wide enough to encompass an environment where a roving LD with Nomad might be working in 5 or 6 different houses in a given month".

Though I've been wrong before.

 

[Jay Ashworth]

Now that your poll has closed, here are the answers I was holding back:

1. You cannot mirror nor be a client to a console running a different version of software than you are. In addition, your fixture library version, keyboard and help languages must all be in sync as well for a client to connect to the primary. Running version 2.x and Version 3.x will definitely not connect properly (if at all) to each other. It is possible to program a show offline and save it in formats that are compatible with each other in either branch. Obviously, features that did not exist would not be available in the older versions.

Yes, we were aware of that last point. Every ETC employee I've talked to so far about this has mentioned it.

Please understand that the people on the sharp end generally seem to consider that a workaround, and a pretty wide one at that.

There are things it's good for, but programming-hot-in-tech is not one of them.

2. As you've discovered, the primary development effort for 2.9.x was indeed to create 64-bit versions of the software to comply with Apple's mandate that apps change to 64-bit. We got most of it right in 2.9.0 but had a couple of bugs near the end of 2.9.0 that caused Catalina support (where Apple does a process notarization) to be delayed until 2.9.1. Eos is not just a single executable and has many utilities and other processes it relies upon for different functions. All of these must also be 64-bit to pass notarization and it turns out that even just recompiling old code with a new compiler can introduce several new behaviours (bugs, features, featured bugs, etc). These things all take time and test effort to ensure that we haven't broken working features just to go to 64-bit. It is just not possible to go back to older code branches and "recompile" as a 64-bit application and expect everything to work due to the complex interactions of the software.

I've heard that notarization item referred to as a "scam" by quite a number of both users and developers...

It seems that all of the modern OS developers have an interest in deprecating support for legacy code be it for sales, vulnerability, and/or support reasons. If you were to time capsule your computer, it would run at whatever versions you had at the time, but you couldn't take advantage of new features. If you had upgraded to take advantage of new features, you might also have to upgrade to the appropriate hardware that supports those features as well. This appears to be the trade-off of the world we now live in.

Well, Apple's called some major flag days over the last couple decades, sure.

But to wind back to the previous paragraph: the 'solution' I'm driving at was "we were already building 2.9.x for 32-bit, and why can't we continue, so it can be run by people who cannot (for many reasons) upgrade to an OS which won't run 32 bit apps?" I don't see that we've actually quite made it to that point here.

[ Looking back, perhaps I framed the poll backwards, as well. :-} ]

It sounds like you may have been misinformed about software releases and were unaware of newer development. 2.9.2 is the current software version of the 2.9 branch. While we are not planning any further feature releases for the 2.9 branch, we do release fixture library updates to support newer fixtures on older consoles as well as may release critical bug fix versions in that branch in the future. New and exciting feature development will occur in the 3.x branch.

I hope that helps.

A little. I had not in fact heard about 2.9 at all when I started this; our old board was on 2.8.3, and our new one came in with 3.0.x.

But it appears, from the poll results, that if there *is* a universe of people who care about this as I'd perceived, they're not *here*... and where else would they be.

Owel, nobody bats 1.000.

Thanks for the clarifications.

 

[kicknargel]

I think the thrust of Nick's speculation was more "perhaps, Jay, the limitations that you see in the current ecosystem are due to ETC not having its view zoomed back wide enough to encompass an environment where a roving LD with Nomad might be working in 5 or 6 different houses in a given month".

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?

 

[Jay Ashworth]

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?

a) Because I couldn't legally install it on more than one machine;
b) Because LDs would walk off with the dongle;
c) Because I decline to accept responsibility for other people's laptops not part of my ecosystem?

And probably 2 or 3 more; that's just what comes instantly to mind.

And, secondarily to a), because they're not *employees*; they're independent contractors; I'm very likely not permitted to loan it to them, legally.

 

[derekleffew]

b) Because LDs would walk off with the dongle;

Remember gas station restroom keys? Nicopress the dongle to a 50# pig weight. I don't know many LDs who carry Felco s.

 

[TimMc]

Remember gas station restroom keys? Nicopress the dongle to a 50# pig weight. I don't know many LDs who carry Felco s.

Designers don't carry anything that would indicate they might participate in manual labor.

 

[kicknargel]

But I mean, why not own the computer, the dongle, the whole system. Isn't it an integral part of your lighting system? When the designer shows up, it's all sitting there on their tech table. That's the way it is at the theatre I'm at now. The theatre used to own the Remote Focus Unit and remote video interface. Isn't this the upgrade version of that? Do you make them bring their own little light and headset?

I get that in practice designers are buying Nomad for themselves, but I don't get why. Is it just that theatres are being cheap about it?

 

[Jay Ashworth]

But I mean, why not own the computer, the dongle, the whole system. Isn't it an integral part of your lighting system? When the designer shows up, it's all sitting there on their tech table. That's the way it is at the theatre I'm at now. The theatre used to own the Remote Focus Unit and remote video interface. Isn't this the upgrade version of that? Do you make them bring their own little light and headset?

I get that in practice designers are buying Nomad for themselves, but I don't get why. Is it just that theatres are being cheap about it?

I haven't interviewed the 2 or 3 I have access to, but I infer it's because they want to be able to write cues offsite, and already own the relevant laptop -- and because (up until supply-chain problems), the Nomad package included 2 universes of hardware, meaning you could use your Eos skills to actually drive lighting wheremsoever you might be, no matter what they had in house.

Also, putting on my House hat, I don't necessarily trust them not to break my (not terribly inexpensive) MacBook Pro.