XP Vs. Vista and Mac OS

[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.

[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.