The new old guy signs in

JAJ

Member
I'm one of the two founders of Dilor, and I designed all the electronics and controls from inception in 1978 to 1988 when I moved on to a new industry.

I bumped into this forum by accident tonight, so I figured I'd sign up and see what was going on in my former field of endeavor.

DMX 512? Really? What has the world come to? I always thought Steve Terry would fix all this crap.
 
It's always nice to meet someone who survived the disco era... :angryoldman:


Welcome aboard. I'm especially glad you're here because most of my theater's equipment is from the 70's. :)
 
It's always nice to meet someone who survived the disco era... :angryoldman:


Welcome aboard. I'm especially glad you're here because most of my theater's equipment is from the 70's. :)

Thanks! Disco, eh? Well, Dilor did have a dimmer rack or two in Studio 54, so I guess I legitimately survived disco...
 
Welcome to the Booth! We love our history around here. Many of us here believe that the only way to be a great technician today, is to be well versed in the the past and how we got here. You can't truly appreciate ACN unless you know what it was like in the bad old days.

Anyone who feels they can take a shot at Steve Terry in their first post must really know their stuff. Beware, he's lurking about the booth and will eventually find you.

Please check out our wiki. Someone with your experience could be a great asset in our efforts to create THE encyclopedia of technical theater.
 
Welcome to the Booth! We love our history around here. Many of us here believe that the only way to be a great technician today, is to be well versed in the the past and how we got here. You can't truly appreciate ACN unless you know what it was like in the bad old days.

Anyone who feels they can take a shot at Steve Terry in their first post must really know their stuff. Beware, he's lurking about the booth and will eventually find you.

Please check out our wiki. Someone with your experience could be a great asset in our efforts to create THE encyclopedia of technical theater.

Thanks for the welcome! I did a little digging on what ACN means, and it sounds useful. My gig was dimmers more than controls, though. Sure, slider controls with PWM fading and lossless diodes and so on, but basically one wire-one dimmer. The CD80 protocol that (I guess) Dave Cunningham came up with was the first few-wire protocol, and it was pretty noise sensitive. I never really got to know Dave, but I spent a lot of quality time with Gord Pearlman and Steve Carlson. Steve Terry I met a few times as well. It was a pretty small universe in those days but it was packed with a lot of brainpower and the pace of innovation was breathtaking. Today, if I wanted to do a console, it would be a web app with a javascript back end. Has anyone done one of those already?
 
Today, if I wanted to do a console, it would be a web app with a javascript back end. Has anyone done one of those already?

Huh...I haven't seen anything like that. Could be interesting... or it could be very finicky and not worth using something like DMX Lightning or MagicQ.
 
CB's own Jchenault was the co-creator of a pretty cool software based lighting control system. It's now being sold by Gam as "Plexus" you can see more about it here. If I remember right, they designed it several years ago for the Ashland Shakespeare Festival in Oregon, although it's had a lot of revision since.

ACN is Steve Terry's baby. He's been one of the people on the standards committee to see that ACN is designed well and help encourage it's adoption across the industry. DMX is well entrenched so it'll take a while to see a complete change over. At this point we have DMX and a lot of proprietary versions of ACN which are supposedly going to allow everything to be future compatible with ACN. The coolest thing about ACN is that it's all off the shelf computer networking hardware. Need a new control cable or router no problem you can get one at Best Buy or the 24 hour Walmart. If you plan ahead you can buy them cheap on-line, or make your own cables. Can't do that quickly, easily, or cheaply with any of the previous control systems.

The other thing that is really cool is the true bi-directional communication which is possible. Check out these notes from a panel I attended at LDI last year on ACN.
 
CB's own Jchenault was the co-creator of a pretty cool software based lighting control system. It's now being sold by Gam as "Plexus" you can see more about it here. If I remember right, they designed it several years ago for the Ashland Shakespeare Festival in Oregon, although it's had a lot of revision since.

ACN is Steve Terry's baby. He's been one of the people on the standards committee to see that ACN is designed well and help encourage it's adoption across the industry. DMX is well entrenched so it'll take a while to see a complete change over. At this point we have DMX and a lot of proprietary versions of ACN which are supposedly going to allow everything to be future compatible with ACN. The coolest thing about ACN is that it's all off the shelf computer networking hardware. Need a new control cable or router no problem you can get one at Best Buy or the 24 hour Walmart. If you plan ahead you can buy them cheap on-line, or make your own cables. Can't do that quickly, easily, or cheaply with any of the previous control systems.

The other thing that is really cool is the true bi-directional communication which is possible. Check out these notes from a panel I attended at LDI last year on ACN.

So, Steve Terry actually IS fixing the control protocol mess. I guess I shouldn't be offering editorial comments just yet. As for bidirectional communication, I presume that will be more useful for high-tech fixtures than for dimmers. Dimmers are remarkably dumb. They couldn't tell a qualified stage electrician anything they wouldn't know by just looking at the stage.
 
Today, if I wanted to do a console, it would be a web app with a javascript back end. Has anyone done one of those already?

We considered it when we built our system - but pretty quickly rejected it. There is just a whole lot of communication that has to go between a 'Fade engine' and the 'User Interface'. At the time it was not easy to push the kinds of data between a backend server and the display. I also would seriously question javascript as the backend. It is not a very robust language for development.

At some point we will likely split our app in two and establish a real service to do the heavy lifting - we might even use HTTP / Json for our messaging. But I don't see the advantage to using HTML in our display.

But I would be interested in the discussion.
 
Dimmers are remarkably dumb. They couldn't tell a qualified stage electrician anything they wouldn't know by just looking at the stage.

Well the manufacturers would love to sell you a smarter dimmer which can tell you it's temperature, if it's actually working, and I think how much of a load it's got on it, and other information too. However the cost was about double if I remember right and most of us can't afford that kind of information, nor do we really need it.
 
We considered it when we built our system - but pretty quickly rejected it. There is just a whole lot of communication that has to go between a 'Fade engine' and the 'User Interface'. At the time it was not easy to push the kinds of data between a backend server and the display. I also would seriously question javascript as the backend. It is not a very robust language for development.

At some point we will likely split our app in two and establish a real service to do the heavy lifting - we might even use HTTP / Json for our messaging. But I don't see the advantage to using HTML in our display.

But I would be interested in the discussion.

I don't know the state of the art in dimmer control protocols, so maybe this is a dumb question, but has anyone built the fade management engine into the dimmer's own control circuitry yet? If not, why not?

Back in 1984, Dilor built a computerized console called the DGM, for Dimmer Grouping Memory. It was, as I recall, 50 (or so) group master sliders to which any number of up to 1000 dimmers could be assigned at any level non-exclusively. Lighting cues were fades from one set of saved group master levels to another set. The multi-cpu modules (Motorola 6809's) and coding (assembler) was the work of Sean Adkins, and frankly it was brilliant.

The reason I mention that bit of history is that the biggest challenge in the design was the huge amount of arithmetic involved in combining all those masters into levels for all those dimmers. These days, the math would be trivial on most PC's and even on some smartphones. However, what would make it even easier would be to put a cpu in each dimmer and just broadcast the master and group levels out and let each dimmer figure out what its own personal output level should be, and when and how much to fade for the next cue.

I guess my view, uninformed as it is today, was that someone had already done this so consoles would be much "thinner" in the technical sense than they used to be when they had to do everything.
 
I believe Kliegl Bros. K96 protocol was the first (and possibly only?) protocol to store the softpatch in the dimmer rack. Then there was Vari*Lite Artisan/Series200 which stored the cues in the fixtures. Today some, but few, systems depend on distributed processing (grandMA/Hog3) to take some of the calculation load off the main console. Some manufacturers say it's necessary when dealing with 16, 32, 64, or more, universes of 512 channels of information. Others disagree.

From the ETC Forum (derekleffew asks, avalentino answers):
"Theoretically, are the 2K, 4K, 6K, etc. outputs limited by hardware or software? I'm just trying to wrap my head around why other manufacturers' huge output consoles use distributed processing and EOS doesn't. Even with Net3/sACN nodes, the console still does almost all of the calculating work, right? I love the analogy that all lighting consoles are just fast and fancy calculators with extra keys to hide the arithmetic. (And the more-advanced consoles use trig. functions to generate effects.)"

The output config of a desk is a software limit. Any console or RPU purchased can be field upgraded to the max allowed by the particular platform with no hardware change. Even at 16K output, we've not run into the need to get into a co-processing system, as the basic hardware can easily support the required functionality. The rig output is completely managed by whatever device is the current master. The gateways are distributing the data, therefore they serve a different function in the rig than similar devices that might be used on other manufacturer's products - and are priced to reflect their role in the system. :)

-------

"Again, hypothetically, I'm guessing that upgrading a Gio 4K to an 8K is less expensive than expanding a grandPA 4K by adding a network signal/processing processor/unit to the network? I like (I think) that ETC is selling outputs in 1,000 or 2,000 batches instead of channels in 100-unit increments."

On an Eos family product, when you upgrade the output, you aren't adding any more hardware - so, yes, I'd assume this is more cost effective than adding another device into the system.

-------
"One last question: Can an RPU be thought of as just another console albeit without a facepanel? Or is it more equivalent to an NSP/NPU/DP8000? Would I ever need/want more than one in a system?"

An RPU is indeed a console without a facepanel, similar to the LPC for the Expression product line. In addition to being used in standard theatre/TV environments, it is often installed in environments that will be programmed from a desk, and then the RPU left to run the show (think environments like theme parks, "architainment" (hate that word, but...). In those environments it is not uncommon to have two RPUs, one as the primary, the other as the backup. The desk, then, when connected to the system, comes online as a client. In a standard theatre/TV setup, you'd generally only have 1 RPU per system. Recommended config (but not required) is that the RPU is setup as the primary processor and the desk itself as the backup. That way, if you ever did have to assume control from the primary, you'd be sitting at the device with a full facepanel.

One last word (or two) on this. System output is determined by the lowest output count between the primary and the backup. So, if you connect a 4K Eos RPU to an 8K Eos, your system output will be limited to 4K. The output capacity of any client is not important. So, if you connect a 1K Ion as a client into an 8K system, the Ion will have access to the full 8K of output serviced by the Primary/Backup. Hope that makes sense.

a
 
I believe Kliegl Bros. K96 protocol was the first (and possibly only?) protocol to store the softpatch in the dimmer rack. Then there was Vari*Lite Artisan/Series200 which stored the cues in the fixtures. Today some, but few, systems depend on distributed processing (grandMA/Hog3) to take some of the calculation load off the main console. Some manufacturers say it's necessary when dealing with 16, 32, 64, or more, universes of 512 channels of information. Others disagree.

K96? I remember the name but I can't put a face to it.

Whatever became of Martin Moore? Patrice Sutton?
 
K96--see Pathway Connectivity Inc. - Lighting Control Protocols - Part 2 :
History -- Kliegl Bros. introduced their new digital control protocol along with the popular K96 fully digital dimmer rack system and the Command Performance console in 1981. The protocol was also used later with the Entertainer and Performer 3 and 4 consoles, and K100 dimmer racks. As conceived, K96 was a powerful protocol that incorporated data compression, high level commands and dimmer talkback features, although these advanced features were generally not used. It also carried softpatch data for storage in the rack processors.

Martin Moore--from td&t | A Theatre Project | Richard Pilbrow :
Martin Moore started in London theatre as a board operator. As chief engineer for Strand Electric, he worked on the world’s first computer boards. In the United States, he has worked for Kliegl Bros, Artec, Fisher- Dachs, and Empac (Experimental Media and Performing Arts Center) at Rensselaer Polytechnic Institute in Troy, N.Y. He is currently active in standards writing.
One of my "path-not-taken/what-might-have-been" moments was when I, while in college circa 1981, decided not to pursue an internship with Mr. Moore at Kliegl Bros.

Patrice Sutton--don't recognize that name.
 
K96? I remember the name but I can't put a face to it.

Whatever became of Martin Moore? Patrice Sutton?

Martin Moore is still around. His last big project was being the owner's rep on the EMPAC project at Rensselaer. He's now quite active in PLASA rigging standards and is leading the project for a stage lift standard.

Patrice Sutton was the Fixtures Product Manager at ETC in the '90's, but she has now completely disappeared from the industry.

ST
 
Martin Moore is still around. His last big project was being the owner's rep on the EMPAC project at Rensselaer. He's now quite active in PLASA rigging standards and is leading the project for a stage lift standard.

Patrice Sutton was the Fixtures Product Manager at ETC in the '90's, but she has now completely disappeared from the industry.

ST

Hi Steve! Thanks for catching me up on their whereabouts. I'm glad things worked out well for you and you've a great gig with ETC.

I really enjoyed the venerable Mr. Moore - very knowledgeable and very personable. Patrice was a load of fun too, but she was at Kliegl when I knew her in the early 1980's. I think she was in sales there, but I don't remember. I guess she did the same thing that I did and switched industries in search of other opportunities.
 
Last edited:

Users who are viewing this thread

Back