XP Vs. Vista and Mac OS

A little off topic but to concur with Marty:

In my own tests I have found Catalyst runs with much greater performance on Tiger, ie more layers of playback. With my system I get 10-11 layers of photo jpeg. On leopard I can get nowhere near this many.

Carbon Copy Cloner www.bombich.com/software/ccc.html is a great way to downgrade your new leopard machines. Its shareware also so is inexpensive.

Ross

I too dream of a day when all my consoles will run under OSX. It seems so counter intuitive that i must "design" lighting in Windows.

Ive been running leopard for a while now and while it still has a hiccup here and there it is almost entirely due to the fact that it is still new and not everyone has prepared for it yet. This goes doubly so for vista, which on its own isnt too horrible, but still gets a really bad rap right now primarily because independent developers were not ready for its release.

As for running consoles on a mac, I have used Hog III, II, and gMA PC using both Parallels and VMware Fusion with great success. However, for any show critical use I always reboot in to the actual bootcamp install of XP that is ultra clean and pristine. Just remember that it still windows and susceptible to viruses. Its a good idea to disable any internet connection and only load on your console software and show files through the OSX share. As for hard drive space, my XP slice is only 5 Gigs. If you make a custom XP installer you can get it down really small after removing such MS staples as Solitaire, MSN Chat, and Outlook Express.

Just to recap,

I have great success with XP with Hog PC. I have a little shuttle PC running 3 monitors, 2 playback wings, program wings, and super widget.
One thing I don't do with the PC is connect to anything else. NO internet, NO networking other than to DL2's. This eliminates viruses and minimizes problems. I also run the system on my laptop with XP and with this PC, I get online and network while running Hog PC. I play games, surf the net and run the lighting program all at the same time with no problems.
Here is the issue we all will be facing soon. XP will see the same fate as WIN 95/98/2000/millenium.
If Vista is already problematic, then why migrate there? Recent history shows that MAC OS is more stable and efficient. If the future includes Catalyst, Axon, Digital lighting, real time virtual programming, and level upon level of DMX universes; shouldn't we be very concerned about the platform on which all of this equipment will be controlled from?
XP is on it's way out. It's only a matter of time until it will no longer be supported, or upgraded. All software manufacturers will be forced to jump on the Microsoft bandwagon with whatever the latest OS is.

I saw the writing on the wall when HOG PC was introduced. I knew Hog 2 was on the way out and all equipment along with it. Digital lighting. media servers and newer technology continues to shape our industry. Are we going to keep creating newer technology without thinking about the platform it operates on. What will we all do when XP does stop. DL2's are windows XP imbedded as is the Road Hog, and IPC.

As lighting designers and programmers, this is our means making a living. I update to new computers every 3 years to keep up with current technology. It's that time again and I need to know where all this is going.
I really don't want to continue with PC because it's just getting worse. MAC is getting better and better.
And the comment was made about Allien computers. It's not the hardware as much as it is the OS. Most PC's are ok. Mine are all DELL. it's the OS that is going to discontinue at some point.

Are we going to keep creating newer technology without thinking about the platform it operates on. What will we all do when XP does stop. DL2's are windows XP imbedded as is the Road Hog, and IPC.

To set the record straight here, regardless of which direction XP Pro goes, it will not affect XP Embedded. XP Embedded is on a completely different roadmap and lifecycle from it's desktop cousin.

From my own perspective, Apple does a much worse job of backwards compatability than MS. For the most part applications than ran under WinXP run fine under Vista. Not all, but the vast majority do. With Mac OS it seems that every time they do an upgrade it breaks every existing application on the market besides their own.

Just my $0.02.

[quote=JeffM]If the future includes Catalyst, Axon, Digital lighting, real time virtual programming, and level upon level of DMX universes; shouldn't we be very concerned about the platform on which all of this equipment will be controlled from?

the System Information Packet. very few people actually know you don't have to begin life with a null start code.

my reasoning suggests that this is due to the cost of implementation being deemed unjustifiable by device manufacturers.

instead, SIP's are in general exclusive to highly specialized diagnostic tools.

i conclude that the factor most influential to a return on including SIP generation/processing capabilities is the specification of a microcontroller or that of a microprocessor.

for years and years and years, your typical DMX recieving devices were spec'd to microcontroller. most DMX receiving devices perform exactly the same operations: read some dip switches to get your address, listen to the DMX, and make a motor move.

now, that process sounds quite simple. realizing such a set of microcontroller instructions however, involves some very very very, very very complicated work.

[INDENT]given the example: a moving light has a 9-way dip switch for address, and a 9-way dip switch for fixture options, but its microcontroller only has 4 "input" pins, and one of these input pins is dedicated to the EIA-485 receiver’s logic high output for the purpose of "reading DMX".
so how do you use only three pins to determine whether 18 separate circuits are open or closed?

a common use of the term "Multiplexing" refers to the method used to read or "poll" dip switch settings.

as we're focused on software, i'll leave the electrical engineering part pretty much ambiguous, except to say one method is to basically 6-fer your 18 circuits into 3 pins, much like how one would 6-fer RGB cyc cells.[INDENT]drop in a bunch of NAND gates so that only one RGB unit is receiving power at any given time.

send power to the first three, read the resulting values from the output side of the switch, move these values into a register, remove power from the first three.

send power to the next three, read the resulting values from the output side of the switch, bit shift and AND these values to the current register, remove power from these three.

repeat until you've got the 18 values you need.

[/INDENT]when you change a fixture's address, you expect it to respond accordingly, right?

for that to happen, that means we need to be checking the address often, which involves repeating that entire process over and over and over and over and over and over and over.

now, if we want to spend our whole life reading our address, that's great, but eventually we're going to have to make time to "read DMX", and maybe even move some motors, too.

just getting an address read into memory is complicated.

reading, parsing, and responding to DMX takes several thousand times the amount of iterations. all of which get their go's from some piece of crystal bouncing around inside a tube. throw into the mess the fact that the 3 input pins also need to spend some of their time monitoring what the motors have done, and your head starts really hurting.




[/INDENT]microcontroller programming is intensive. it takes tons of work to get it right, especially when the notion of time is involved, as is the case with decoding DMX.

to further complicate, microcontroller programming is not performed by coding in modern high level languages. it's usually done is a variation of Assembly, specific to the make/model of the microprocessor. (read: if you change chips, you have to throw away most of your code and start over). there are of course some Hi-Tech tools that can make coding easier, even to the point of extending ANSI C, but even the code used in the tools is relegated to only being useful when deployed to one single family of microcontroller. (read: just because you spent a month writing code for the microcontroller doesn't necessarily mean you have a single line of code that can be compiled into a different kind of controller, let alone into an actual desktop application)

bust open a bunch of different fixture models from the same manufacturer's era, and you'll most likely find the exact same microcontroller in every one, illustrating the point that being able to re-use already-existent code is so crucial to business success, that manufacturers will still spec the same microcontroller that they already own code for, even if it's NRND or discontinued.

so, given the enormous amount of work required to interpret a NSC DMX packet, it's very easy to decide that adding the capacity to additionally interpret a SIP DMX packet to a simple microcontroller-controlled fixture is a financially unsound idea.


as i see it, ACN is what's going to give a swift kick into specing microprocessors.


and guess who's here, ready and waiting.

the Microsoft .NET Micro Framework

it's a quiet revolution. the 9 to 5ers will never even notice. but i expect the "upper third" is paying very close attention.

there's something magic about spending a week describing to the .NET Framework how your world works. it's so elegant that several institutions here in Silicon Valley have honored it as an art form, to the point of offering MFA programs in exactly that. (functional programming is design, IL emission is science, it's that simple.)

the .NET Compact Framework (which runs on Windows CE, in addition to Windows Mobile) revolutionized the embedded device market (not to be confused with the Windows Embedded market, that runs the full framework...). think cash registers, machine control panels, home automation, routers, tv set-top boxes, mobile phones, xbox/dreamcast, etc...

and now the .NET Micro Framework. replacing every 8051, every PIC, every motorola & ti, with (usually) an ARM7 or an ARM9.

but the best part is how all three editions of the framework work together.
as long as your business logic is properly separated from UI/IO, every line of logic you write for the desktop can be compiled for the Compact or Micro Framework, without making a single change, ever. conversely, if you start by targeting the Micro Framework, every line can compile to the full or Compact Framework, again, without any changes.

this massive realization of code re-use has implications far, far beyond the scope of this little thread; there are even more important benefits to having a common runtime present on every kind of device.

in other words, if you describe a NSC DMX packet to your desktop application, you don't need to again describe it to your fixture; it will already know. if you decide to change microprocessors, it will still know. if you later decide to make a PocketPC RFU, it too will know.

if you decide to implement SIP, that's all too easy. everyone already knows that NSC is a kind of DMX packet, since SIP is just another kind of DMX packet, all you have to do is describe SIP once, and everyone will be able to handle it.


put that all together and consider ACN's DDL.


DDL uses XML. XML is essential to all the .NET Frameworks.

not having to re-invent an XML parser/serializer in Assembly is probably by itself enough of a reason to choose the .NET Micro Framework as your new platform. the fact that you can create your DDL interpreter exactly once means that your hardware guys can spend their time in the ratsnest instead of spending years on this XML thing that has nothing to do with their motors, just to spit out a freakin UUID which, again, has nothing to do with their motors.

having a DDL interpreter to re-use allows the mobile team to build that sexy little interface for your RFU while the desktop team works on the 3D visualizer, instead of everybody re-doing all the freaking work at every single step on every single platform.

and the DDL's just one example. the same applies to your control. we've clearly learned that lighting is getting more compute-dense, requiring distributed processing schemes. in addition to being less work, having the controller (4PC?) and controlee (DP8000) share their definitions of control signals always results in fewer stupid mistakes / hard to find bugs! with ACN allowing manufacturer-specific uses over the line, you'd better believe things like media center preview / stock browsers are going to become super common. i'd love to see the industry pull together as a whole and agree on a way to make use of the .NET Plugin architecture to enable this kind of experience; it's the perfect way to produce results without sharing source code, just a well-documented IInterface, usable in every language.


the future's getting complex, fast. the only way we're going to keep up is if we get every one of these instruments on the same page. ACN is why, .NET is in my opinion how.


the information required to get .NET running on an Apple product has been available freely to Apple Corporation (actually to anyone) for many years. Cocoa isn't even available on their own mobile offering; not having an embedded (micro) offering means any lighting solution involving a mac is at minimum 2x the amount of code. it's strictly business, buddy.


[quote=SBlair]Apple does a much worse job of backwards compatibility than MS. For the most part applications than ran under WinXP run fine under Vista.
i just want to emphasize this. the Application Compatibility Layer is one of THE most underappreciated parts of the system. its capacity to intercept and re-route calls is phenomenal.

Quinn,
Could you rephrase that?
Only kidding. Wonderful post. After reading it, I feel like I earned some school credits.
Thanks,
-jc

[quote=rosswill]A little off topic but to concur with Marty:

In my own tests I have found Catalyst runs with much greater performance on Tiger, ie more layers of playback. With my system I get 10-11 layers of photo jpeg. On leopard I can get nowhere near this many.

Carbon Copy Cloner www.bombich.com/software/ccc.html is a great way to downgrade your new leopard machines. Its shareware also so is inexpensive.

Ross

Did you run into any driver issues with the graphics card or other hardware?

No but you need to be careful here for sure. This will change as each machine gets further away from the Tiger ones. Latest graphics drivers are always easilly available to download however I have found.

Ross