Is a Windows based console really a good thing?
- Thread starterJezza
- Start date
I've got some punchcards here that you can use...
Note that some consoles (The Strand Palette/Light palette) use Embedded Windows XP, not standard desktop windows. Unless you've been working in embedded systems development, you have no basis of comaprison.
The Key requirement for a console OS is "real-time" operation; i.e. not having to suddenly wait for your cue to execute while the OS is off doing other things. Embedded XP is designed for this, and is also hardened against being mucked with by the users. There are some variants of Linux that are similarly designed, in addition to several custom systems, such as VXworks. AFAIK, Apple doesn't make an embedded version of OS-X, as their market is strictly interactive users.
Developing for Embedded Windows also has the advantage that an off-line version is easy to produce, as the code is nearly identical to the console code; if the console ran on Linux or VXworks, then they would need to spend additional $$$ on a windows version for off-line use. Note that if the console were Mac-based and the off-line version were also Mac-only, then I could run my off-line version on my Mac, bot not my PC. If the off-line version is PC-based, then I can run it on either my PC, or my (Intel-based) Mac.
So, yes, I will accept that Windows-based consles are the way most manufacturers will go; and if they use Embedded Windows, they will be as stable as any other OS (even VXworks can crash), and they will be able to offer additional features (such as off-line editors and remote control) at a lower cost.
Last edited:
Fred I don't think I want an off-line ass editor.
Anyway, I want to point out that there seem to be two different topics discussed here.
Topic #1 Consoles like the Strand Palettes that are switching from being DOS based to using embedded Windows XP as their OS.
Topic #2 Computer based lighting software and a dongle. Why are none of these products Mac/Linux based?
As far as topic #1 I'm a P.C. guy and I'm very comfortable with XP in my console. Especially with the added stability of it being embedded. I'll Keep the console disconnected from the outside internet and, if I catch someone as much as playing solitaire on my console they'll find them self sorting screws in the shop for a month.
As far as topic #2 it seems odd that someone out there isn't designing light console software to be run off of a Mac or Linux. Maybe it's just the numbers game of going with the largest number of potential customers. This doesn't make a lot of sense to me as there are a lot of loyal Mac users out there who would go out of their way to buy a product if it ran on their system. It seems like if one company came out with a Mac version of their console software they could really clean up.
soundlight
Well-Known Member
As has already been mentioned, that would take alot of work with Apple, because only Apple machines can run OS X. This is most likely the major issue blocking the use of the Apple OS for consoles.
Also, as has been stated before, an embedded OS with blocks on user customization is alot more stable then the straight up windows OS, which does have some problems, but is no more stable than the Mac OS. Sure, it requires virus protection, but so does OS X. You may not know it, but there is a team of folks working hard at Apple to make sure that a Mac virus is never developed. Nice of them, isn't it?
Personally, I wish that everyone would just go back to using DOS, just about the most rock-solid OS ever.
Also, as has been stated before, an embedded OS with blocks on user customization is alot more stable then the straight up windows OS, which does have some problems, but is no more stable than the Mac OS. Sure, it requires virus protection, but so does OS X. You may not know it, but there is a team of folks working hard at Apple to make sure that a Mac virus is never developed. Nice of them, isn't it?
Personally, I wish that everyone would just go back to using DOS, just about the most rock-solid OS ever.
JD
Well-Known Member
What I would love to see is server-side DMX control. (ex: a server and DMX interface on stage, a workstation in the control booth.) The advantage here is it would be platform independent. The workstation would log into the server and run the show in a browser interface. (in other words, no special software on the workstation.) Network speeds are 100m+ which would transparent to DMX control which is about 250k. Also, server OS software tends to be more stable. You could also have multiple workstations all running the same show, or even grab a wireless laptop and sit in the audience!
Funny, the gaming industry already has all this software figured out! (Just ask a video game nut)
Well, we can dream can't we?
Funny, the gaming industry already has all this software figured out! (Just ask a video game nut)
Well, we can dream can't we?
wakkoroti
Active Member
http://www.interactive-online.com/cueserver/
This does a little bit of what you said, it's just not very pretty.
They have had variations of that for a long time. They are playback controllers. Strands is the 510i, which you can connect through an xconnect dongle and your good to go. When you pull off of it, it can run a show through SMTP, go button, what have you. Essentially a console in a stand alone box. ETC, High End, and a host of other company's make them. The web access thing isnt there yet, but then again Xconnect is a simple dongle and your good to go, no software to install.
PadawanGeek
Active Member
I've had six crashes on my Windows XP embedded Congo since September; that's crashes, as in everything locks up & you reboot the console. ETC thinks some of these were software issues, but they can't recreate & identify the cause of most of them, despite having the show & log files. Whether it is a software or hardware issue really doesn't matter to me, I just need a reliable lighting controller and the Congo (unfortunately) has not proven to be reliable for me.
After Barry Bond's record breaking HR season a fair number of other players started trying mahogany bats. Bond's response, "It's the warrior, not the weapon..." One could argue that it is the warrior, and his chemical enhancement, but the point is still solid.
I am an OS atheist. My first serious exposure to a commercial OS was writing floppy disk support for CP/M (yes, I remember when it was Intergalactic Digital Research). The first time I sent a PC on the road as a controller was a Mac SE on Pink Floid's Momentary Lapse of Reason tour ('87). I've since done commercial development for Mac, Linux, Next, every versions of Windows, and countless commercial kernels.
When Daniel and I decided to do our current controller, we were at a toss up on rather to go Mac or PC. PC had some cheap platform advantages, but Mac seemed under served and we both liked OS X a *lot* more than previous Mac platforms. Linux wasn't even a consideration, between limited desktop deployment and serious technical limitations (even the threading priority model was still broken at the time), it just wasn't interesting - though I'd just targetted the kernel on several project. So we did million operation tests to settle our own PC/Mac debate. 5 runs on each platform. Bottom line 10.2 had a threading bug, and no Mac run got past 500,000. Win 2K and XP went 5 for 5, and all Win95 derivitives had too much latency and dither. So we went Windows and limited to 2K and newer (no 95/98/ME support). If 10.4 had been out, we'd probably be Mac based.
The moral is basically what others have expressed. A controller is a lot more than the OS inside it. Note that none of the OS's mentioned (Mac, Win, Linux, etc.) are RTOS systems, so some engineering has to go into a real time system (albiet a not terribly demanding one) like DMX. So, judge the controller based on its own performance, not any preconceived notions about one part. Similiarly, if a controller proves to be unreliable crap - blame the programmers not the OS. Over the years, I've gotten decent reliability out of even some mega klunker OSs like GEM and the Amiga (principally by bypassing them), so I have no sympathy for mission critical pieces of equipment that are not up to snuff.
-jjf
I am an OS atheist. My first serious exposure to a commercial OS was writing floppy disk support for CP/M (yes, I remember when it was Intergalactic Digital Research). The first time I sent a PC on the road as a controller was a Mac SE on Pink Floid's Momentary Lapse of Reason tour ('87). I've since done commercial development for Mac, Linux, Next, every versions of Windows, and countless commercial kernels.
When Daniel and I decided to do our current controller, we were at a toss up on rather to go Mac or PC. PC had some cheap platform advantages, but Mac seemed under served and we both liked OS X a *lot* more than previous Mac platforms. Linux wasn't even a consideration, between limited desktop deployment and serious technical limitations (even the threading priority model was still broken at the time), it just wasn't interesting - though I'd just targetted the kernel on several project. So we did million operation tests to settle our own PC/Mac debate. 5 runs on each platform. Bottom line 10.2 had a threading bug, and no Mac run got past 500,000. Win 2K and XP went 5 for 5, and all Win95 derivitives had too much latency and dither. So we went Windows and limited to 2K and newer (no 95/98/ME support). If 10.4 had been out, we'd probably be Mac based.
The moral is basically what others have expressed. A controller is a lot more than the OS inside it. Note that none of the OS's mentioned (Mac, Win, Linux, etc.) are RTOS systems, so some engineering has to go into a real time system (albiet a not terribly demanding one) like DMX. So, judge the controller based on its own performance, not any preconceived notions about one part. Similiarly, if a controller proves to be unreliable crap - blame the programmers not the OS. Over the years, I've gotten decent reliability out of even some mega klunker OSs like GEM and the Amiga (principally by bypassing them), so I have no sympathy for mission critical pieces of equipment that are not up to snuff.
-jjf
Every so often someone brings up the issue of console stability. Some argue that pc based is bad, because Windows is bad. But in my experience and in the experience of most LightJockey users, that's just not true. In 6+ years of doing shows, I've never had a crash. AND I was running dj software for the first 5 of those years on the same pc, at the same time. Usually, if the software is stable, then the platform will be fine. If the software isn't, then there's nothing you can do. It will crash.
Sorry to be anal, but RTLinux is more of a micro kernel than an operating system. Although it is not as feature rich, it had threading and interrupt management which is similiar to Kadak's AMX (best known as the micro kernal under PalmOS, at least on all the original 68K derivitive basd palm pilot type devices). It certainly would be a big help for someone doing certain types of real time, interrupt intensive, hardware support. However, I'm not sure it would be all that helpful for many DMX controllers.
The problem is that Linux proper then runs as a single, low priority RTLinux thread (the Linux, psuedo posix, thread system then runs under the single RTLinux thread). So a lot of the reasons that a desktop OS is often selected (I want to use the sockets implementation to talk ArtNet, I want to use an existing USB stack to talk to hardware, etc...) are not really accessible to the more robust, pre-emptive RTLinux threads - since you have to use data exchange (fifo, shared memory, etc.) and syncronization to get the data into the low priority Linux thread which, in turn, will handle the requests with the same priority and latency as if RTLinux was not there.
To me, it is also something of an irony that the commercial implementation has been acquired by Wind River. I think it was Wind River's pricing and licensing policies for VxWorks that sent so many companies to Linux for embedded applications in the first place.
-jjf
OK, you've had crashes. But is it the Congo software that's causing the crashes, or the OS ?. Chances are, given the newness of Congo, that there lies the problem, which might well has nothing to do with the OS.
I've been using an XP embedded Emphasis system for 8 mos. with no burps, re-boots or crashes of any kind. Go figure, as I suspect Emphasis would be full of bugs as ETC essentially stopped any further upgrades. I also suspect that additional experiences with the assorted Congo versions will give ETC and the AVAB developers additional data that will make your crashes go away.
Steve B.
Hey I had Micro Kernals for Breakfast this morning ! They're Tasty and don't lose their crunch in milk.
Similar threads
