Designing a lighting program

mozsey

Member
I was talking to my friend the other day, and realized that he's a programmer. He programs video games mostly, but he said he's also versed in creating programs.

My question to the Control Booth community is:

If I were to work with him to create a lighting design program, what features would you want to see?

I was already wanting to put in visualization and control through USB to DMX, but I want to know what the rest of the community wanted. Also, I want to make it affordable.
 
Take all the best features of every existing control program, but omit the bad parts? :p

Honestly, speaking as someone who's worked on the most deceptively simple-sounding software systems, this is a huge task. Jumping right away to things like visualization, output modes, etc. will most likely leave the project stalled with a few neat features but no solid infrastructure beneath them. I've done this type of designing in a past day-job, and while it's not strictly necessary, almost every project failure I've ever seen can be traced back to this step.

Nevertheless, here's my wishlist, in no particular order:
  • Cross platform: *nix+osx+windows please, and with native UI widgets
  • Works with all the common USB-DMX adaptors
  • The same for all the common DMX-over-IP protocols
  • Free
  • Ability to reuse fixture profiles from existing vendors
  • Apps for iOS, Android, plus a webapp for my PlayBook (also free)
  • Multi-touch support for Win8 tablets et al
  • Traditional command-line interface that can be switched between ETC and Strand "mode," plus options for customizing those profiles
  • Built in magicsheet type functionality
  • Fully scriptable in Lua, Python or similar
  • .NET, HTTP REST, and telnet API
  • Headless mode so it can run on my Rasberry Pi
  • Ability to use a secondary pointing device (trackball, tablet, etc.) or joystick/game controller attached to the machine as a dedicated ML steering device, level wheel, crossfader, etc.
  • Never crashes or locks up (ahem, PaletteOS)
  • If it has to crash, don't drop DMX output or halt running cues, and make it restart in <10s
  • Fully configurable window/panel layout + multi-monitor support
  • Built in showfile revisional backups ala OS X's timemachine backups
  • integrated RDM functionality
  • a UX/UI designer involved at an early stage
  • Nice looking graphics
  • 24/7 toll-free phone support by people who know what they're talking about, and have a decent grasp of English
  • Configurable master/slaving, like ETC's RVI, strand's whateverit'scalled, etc, but... better
  • A well written manual (what can I say, I'm a dreamer)
I'd be happy with maybe 1/8 of these.
 
Take all the best features of every existing control program, but omit the bad parts? :p

Honestly, speaking as someone who's worked on the most deceptively simple-sounding software systems, this is a huge task. Jumping right away to things like visualization, output modes, etc. will most likely leave the project stalled with a few neat features but no solid infrastructure beneath them. I've done this type of designing in a past day-job, and while it's not strictly necessary, almost every project failure I've ever seen can be traced back to this step.

Nevertheless, here's my wishlist, in no particular order:
  • Cross platform: *nix+osx+windows please, and with native UI widgets
  • Works with all the common USB-DMX adaptors
  • The same for all the common DMX-over-IP protocols
  • Free
  • Ability to reuse fixture profiles from existing vendors
  • Apps for iOS, Android, plus a webapp for my PlayBook (also free)
  • Multi-touch support for Win8 tablets et al
  • Traditional command-line interface that can be switched between ETC and Strand "mode," plus options for customizing those profiles
  • Built in magicsheet type functionality
  • Fully scriptable in Lua, Python or similar
  • .NET, HTTP REST, and telnet API
  • Headless mode so it can run on my Rasberry Pi
  • Ability to use a secondary pointing device (trackball, tablet, etc.) or joystick/game controller attached to the machine as a dedicated ML steering device, level wheel, crossfader, etc.
  • Never crashes or locks up (ahem, PaletteOS)
  • If it has to crash, don't drop DMX output or halt running cues, and make it restart in <10s
  • Fully configurable window/panel layout + multi-monitor support
  • Built in showfile revisional backups ala OS X's timemachine backups
  • integrated RDM functionality
  • a UX/UI designer involved at an early stage
  • Nice looking graphics
  • 24/7 toll-free phone support by people who know what they're talking about, and have a decent grasp of English
  • Configurable master/slaving, like ETC's RVI, strand's whateverit'scalled, etc, but... better
  • A well written manual (what can I say, I'm a dreamer)
I'd be happy with maybe 1/8 of these.

All of that seems completely doable. I barely sleep as it is, so I could always be available lol.

I wouldn't make it free, I'd probably charge cheap though. Like, 10-50.

The UI will be completely user friendly.

As for no DMX drop out, I could design a USB to DMX module that will hold show information with a GO on it so you can run the show while you're waiting for the computer/program to reboot.

As for reuse fixture profiles, I'd have to look into going to ETC and Strand for that. I don't know how they feel about someone using their existing profiles. But I would do what ETC does, create fixture profiles on a demand basis. I'd also include pre-built profiles for common ML fixtures.

Smartphone/tablet apps would be a given, and when you buy the program for whatever the cost is, the app is included.
 
... As for no DMX drop out, I could design a USB to DMX module that will hold show information with a GO on it so you can run the show while you're waiting for the computer/program to reboot. ...
DMX512 does not work that way. The transmitter must keep sending out 512 values at (up to) 44 times a second, or most receivers (except those with a hold last look function) will determine there's no DMX: dimmers will fade or black out, ML parameters will all go to zero. I can't think of any console or PC software that will maintain DMX output during a reboot.

... As for reuse fixture profiles, I'd have to look into going to ETC and Strand for that. I don't know how they feel about someone using their existing profiles. But I would do what ETC does, create fixture profiles on a demand basis. I'd also include pre-built profiles for common ML fixtures. ...
You're only seeing the front end; much goes on that you can't see. Many console manufacturers rely on a third-party company to supply them with calibrated fixture profiles, based on actual units. See also http://www.controlbooth.com/forums/lighting-electrics/20882-profiles-personalites-libraries.html and the wiki entry Carallon.
.
 
For my no DMX drop out, I was talking about designing a module, basically a mini-computer that will have the show file on it, and if the program on the computer craps out the module would pick up where the computer left off. Think of it as having a dumbed down version of the program. So now you have two consoles, one for back up.
 
My request would be don't try to create software for everyone. Instead choose a target user and create a program for that user's need. Consoles are designed for specific usage situations... just look at all the variations in the Strand family! Unfortunately lighting software tends to try to do it all. I would love to see a software solution designed specifically for the needs of the small community theater/schools/church market. Low budget places with less than 96 dimmers (probably more like 48 or less) who occasionally rent a couple of movers, rotators, or LED fixtures. Make it easy to teach. Easy to program and walk away leaving a monkey to operate it reliably. The software version of the Smartfade.
 
My request would be don't try to create software for everyone. Instead choose a target user and create a program for that user's need. Consoles are designed for specific usage situations... just look at all the variations in the Strand family! Unfortunately lighting software tends to try to do it all. I would love to see a software solution designed specifically for the needs of the small community theater/schools/church market. Low budget places with less than 96 dimmers (probably more like 48 or less) who occasionally rent a couple of movers, rotators, or LED fixtures. Make it easy to teach. Easy to program and walk away leaving a monkey to operate it reliably. The software version of the Smartfade.

I was trying to create something like this, but with availability to expand it for bigger venues and bigger systems.

I do understand the target audience, though. It's better to start big, and dumb it down though. I'm looking for EVERYONE'S input, then seeing where I can go from there.
 
actually, if you had some programming background, its easier to add features than it is to start huge and work your way to easy. If he's a good programmer it should be relatively easy to change the way the software's front end interacts with the user. I have a piece of software in early stages of development (read Planning) that is similar to what is being requested although its designed much more for the tablet market for the "physical" handles. planning on putting encoder wheels as well as timing fader as well as channel strips. The command line will also be built in but can be enabled in the options menu for tablet computers with keyboards to be used. Might look at getting some X-Keys setup for physical buttons and possibly do either a USB or ethernet (for artnet or other). Again this is early stages of planning, Feature outline and GUI draw up and Method layouts.

I'm skeptical to put in scripting or headless features as thats not the market I am aiming for. I am pushing for more of a concert type market, Par cans with movers and hazers rather than cues or specific lighting looks. May not be the simplest software but I will definitely make it fairly simple to understand.
 
actually, if you had some programming background, its easier to add features than it is to start huge and work your way to easy. If he's a good programmer it should be relatively easy to change the way the software's front end interacts with the user. I have a piece of software in early stages of development (read Planning) that is similar to what is being requested although its designed much more for the tablet market for the "physical" handles. planning on putting encoder wheels as well as timing fader as well as channel strips. The command line will also be built in but can be enabled in the options menu for tablet computers with keyboards to be used. Might look at getting some X-Keys setup for physical buttons and possibly do either a USB or ethernet (for artnet or other). Again this is early stages of planning, Feature outline and GUI draw up and Method layouts.

I'm skeptical to put in scripting or headless features as thats not the market I am aiming for. I am pushing for more of a concert type market, Par cans with movers and hazers rather than cues or specific lighting looks. May not be the simplest software but I will definitely make it fairly simple to understand.

I was thinking more start big for ideas, have my programmer work it down to what I want the bare essentials to be, then working my way up from there.
 
You may want to start small. I mean, really small. Get a proof of concept that you can read-in DMX from an outside source, then see what other formats you can read-in. A reason why DMX is not necessarily the gold standard for this application is that then you limit the usage of the application to only people with a physical console next to them. Anyone trying to pre-viz via an offline editor would be left to fend for themselves.

My advice is to proceed with cautious optimism. I don't mean to rain on your parade, but if what you're talking about undertaking was as easy as you make it sound, why are there so few pre-viz applications out there and why do they all cost a fortune? Why aren't those applications meeting all of the points that have already been requested in this thread?

Also, take a moment to carefully ponder which direction you really want to be trafficking data. Do you want to receive it or transmit it? There's talk of it transmitting DMX via USB adapter, but I don't know any standalone pre-viz applications that do that. The common standard is to let the console transmit the data, generally via an IP-based network, and then the pre-viz only receives data in and shows on on the screen which channels the console has told it to turn on. Do you even want this to be a pre-viz application or do you instead want it to be a lighting controller?

I fear you don't yet know exactly what you want this application to be capable of and what purpose you want it to serve, and you should figure that out and research how other software developers are doing similar things -- preferably before you start asking a programmer to write any code for you.

In software development, the fastest way to ensure a project's demise is to try throwing too much into it at once. If this is actually something you intend to do, start small. Establish a proof of concept that you can get data into your application from a console and then start building the application up a couple features at a time. Try to do it all at once and you'll be frustrated that nothing works because so many features were attempted to be written in at once that the programmer cannot possibly debug them all in a sane amount of time. Baby steps, baby progress. Try at first for giant leaps instead and you'll risk giant headaches.

There are companies out there with entire teams of developers working on similar applications and have been for years. Don't expect that overnight you'll spring like Athena out of Zeus' head into success. It will be a long process with a lot of compromises, especially if this a side project that isn't helping contribute to you or your programmer's monthly rent checks or grocery shopping.
 
For my no DMX drop out, I was talking about designing a module, basically a mini-computer that will have the show file on it, and if the program on the computer craps out the module would pick up where the computer left off. Think of it as having a dumbed down version of the program. So now you have two consoles, one for back up.

Forgive the skepticism, but it's not computers that crash, it's the programs running on them. Merely moving the most complex part of the system to an embedded controller will not stop it from crashing, the only way to achieve that is extensive testing.

As other people have said: start small and take it slow. A few hours of planning at this point can easily save you, depending on how far this goes, anywhere from days to weeks of work later on when you're trying to add Feature X or fix Bug 123.

While planning for future expansion is definitely advisable, if taken too far you'll end up planning a complete virtualized operating system that does everything and more, at which point you might as well toss out the original idea and sell your company to Oracle.

The world of lighting is massive, and to become a success you don't need, or even want to be everything for everyone .
 
I was thinking more start big for ideas, have my programmer work it down to what I want the bare essentials to be, then working my way up from there.
Hi mozsey. Did this project ever go anywhere?
 
I didn't see the time stamps on this page and I was going to suggest make a cheap, basic, but good looking drafting software.
 
How close did I come to what everybody wanted with this: Cue Player Lighting?
I saw this the other day when I was trawling the net. It looks interesting but I wouldn't risk a lighting show on Windows. Mac might be a possibility, but I'm not running Yosemite on mine yet. I was more interested in design and plotting features, esp. paperwork. I work in small community theatres (amateur) who cannot afford the likes of WYSIWYG, Vectorworks or Lightwright. I'm a little surprised that there is no open source project trying to fill the gap.
 
I saw this the other day when I was trawling the net. It looks interesting but I wouldn't risk a lighting show on Windows. Mac might be a possibility, but I'm not running Yosemite on mine yet. I was more interested in design and plotting features, esp. paperwork. I work in small community theatres (amateur) who cannot afford the likes of WYSIWYG, Vectorworks or Lightwright. I'm a little surprised that there is no open source project trying to fill the gap.
Guess what eos and Congo consoles run *beats dead horse*

Sent from my XT1060 using Tapatalk
 
Guess what eos and Congo consoles run *beats dead horse*
Sent from my XT1060 using Tapatalk

Yeah, yeah, yeah. But, as I understand them (and I've never used them), they're pretty specialised pieces of hardware and any Windows component will by customised to the hardware. Not the same as running a show from a PC with a USB dongle! *see your dead horse beaten and takes it outside to shoot it*
 
Not for nothing, but we've run over 30 shows and not had a problem with Windows or our DMX King dongle. We keep up with Microsoft updates and don't go web surfing with it.
 
Not for nothing, but we've run over 30 shows and not had a problem with Windows or our DMX King dongle. We keep up with Microsoft updates and don't go web surfing with it.

That's good, but I've been using Windows since it came as a run-time for Excel on DOS machines, and it really is too unstable for me to consider it in a real-time situation, without (as you say) considerable maintenance. Plus, I can't really afford to devote a separate PC to lighting at our theatre. Not when we've already got a console (Theatrelight Nova 32, which is quite sufficient for our small needs).
 

Users who are viewing this thread

Back