We've been reduced to the status of consumers and nobody seems to object. Think of the imagery: a creature with a huge mouth and an enormous gut, no brain and no soul. Consumers get points for consuming junk, the more they consume, the more points they get. They can retrieve these if they can remember their PIN numbers because unlike the customers of another era who had names, consumers have numbers. When they've gorged enough, they can consume more, and they seem to believe that these points are bonuses....

And yet, there is no consumer rebellion. Men, women and children all press buttons and follow instructions like robots with nothing better to do. They're not customers demanding service, they're consumers attached to some enormous electronic teat that will feed them what it wants, when it wants.

A LASER, which is technically an acronym that stands for Light Amplification by Stimulated Emission of Radiation, works in general as follows:

A resonance chamber is filled with some substance and "stimulated" in some manner so it wants to release photons. The photons a substance releases will be of certain frequencies corresponding to the substance's emission spectrum. The chamber is an integral multiple of of the wavelength that you desire.

In my previous post, I discussed the practical matter of how to hold the outline structure we've built so far together. Having created a strong base, it is now fruitful to consider how to extend the data structure to handle the wide variety of outline structures I want Iron Lute to be able to manipulate.

Node Types

One of the most interesting possibilities inherent in this structure is to formally recognize that there are a lot of potential different types of nodes that can be built.

Slashdot recently posted a panicky article about HR3261, the "Database and Collections of Information Misappropriation Act".

I read the proposed bill. Based on the Slashdot summary, especially the phrase "goes directly against the idea that nobody can own a fact", I was hoping to be able to perform a bit of judo on the legal system. If ownership of the database implied ownership of the facts within, then we could all form a corporation and give it our privacy-sensitive information (links to definition of this term) like our address and phone number, then sue people who use them against our will. We might have had some hoops to jump through (incorporating, meeting the creativity standard), but it probably could have been managed.

My wife recently got into Stargate: SG-1, a high quality science fiction television series that I was already a fan of.

The premise is that the United States Air Force is in possession of a "Stargate", a device that connect to other Stargates throughout the universe, analogously to a phone system, and send things there, including people. There are a wide variety of aliens in the universe at various technology levels from "just discovered fire" to "godlike", many of which did visit Earth in the past. The storyline proceeds from there.

We have a new telephone system coming in here at work. It is uniformly an improvement over the old system, at least on a technical level. It did, however, require purchasing new phones to go with the new system.

I want to shoot whoever designed them.

Or at least make him sit in this room with us for a week or two.

He (and I highly doubt it's a "she") seems to be under the impression that the job of a phone ring is to force you to pay attention to the phone. The phone has not done its job until you pick it up. So it is loud and shrill, and based on the how successful the sound is at being both of those things, I'm quite confident in declaring these characteristics were definately concious design decisions.

In my previous posts, I've answered the question "What Is An Outline?" from the point of view of Iron Lute. The resulting data structures are somewhat complicated. These data structures are at the heart of Iron Lute; if they fail, the entire program can come crashing down. Moreover, if nobody is capable of correctly using the data structures, they are still useless. It's worth discussing

Theory to Practice: How Do We Hold This Together?

One significant advantage a more conventional outline has over the outline structure I've built up here is that it is much easier to store the traditional outline in a file. Using XML, traditional outlines are almost trivial to store:

<node text="A">
  <node text="B" />
  <node text="C" attribute="D" />
  </node>

Even if you don't read XML, you can quickly learn to read this format. About the only difference between what I just wrote and the official OPML specification is that OPML adds a <head> section that includes some metadata about the outline, and uses "outline" instead of "node".

And now for something a little different: Dos and Don'ts for DVD commentaries. I enjoy them but it seems somes producers need help.

• DO include commentaries, unless it's a DVD set of some television show that just can't sustain interesting commentary for an entire season. (For example, Friends, which correctly only includes commentaries for three or four episodes per season, which based on my sampling is almost three or four commentaries too many. I don't mean this as a crack at Friends, which I've come to enjoy, there just isn't enough to say about it per episode.) They are cheap (I assume) and add a lot of value for the True Fans; this is especially important if you have a franchise.
• DO include the original audio track under the commentary, having it drop quieter when the commentators talk and coming back when they stop. It is spooky to watch a movie with no audio coming from it at all. It also gives the commentators a chance to refer to things in the video and have us actually hear them if they want.
• DO NOT be afraid of spoiling the current video; you may safely assume we are fans if we're listening to the commentary and we've seen the video already. DO NOT spoil any other video (other movies, future or even past episodes).
• DO NOT narrate the action. Again, you may safely assume we've seen the video, and I don't need to turn on the director's commentary to find out what is happening or what is about to happen. Exception: You may refer to a scene to set context if you intend to discuss it slightly before it occurs, e.g.: "In the next scene, Johnny accidentally sets off the bomb. This posed special challenges because...", narrated on top of a scene you otherwise have nothing to say about.
• DO discuss: Experiences you had during filming, inside jokes, cameos, alternate scripts or actor's ad-libbing, original and unused ideas for the script, what was cut and why, mistakes left in the final product, interesting history surrounding the release ("We had to delay this episode a year because of 9-11").
• DO NOT discuss special effects, unless they are extremely novel or involved novel challenges for the actors. It may still be better to save it for a featurette. Computers have done a lot of unification of special effects techniques, and as a result, they've made almost all special effect featurettes sound virtually identical. Exception: Movies from before the modern special effects era: I find early 80's or late 70's (TRON, Star Trek: The Motion Picture) special effects discussions really interesting because of how wildly different they are from modern techniques.
• DO have at least a sketch of a plan for you want to talk about.
• DO make sure that if you are going to crack jokes that they are actually funny.
• DO NOT spend a whole lot of time praising somebody you happened to work with. Yes, it seems to be part of Hollywood culture to praise someone up the wazoo everytime you mention them, but the praises are stereotypical and unconvincing, especially if you praise a lot of people. Stick with their role and at most a quick adjective.
• DO NOT be afraid to do some mimimal editing to the commentary tracks; if you crack up in laughter, make a comment to your sound guy, please edit it out. If you're not sure if someone is coming into the commentary later or if something is coming in this episode or the next, please pause the commentary and check. (It seems silly when the series creator or movie directer is mumbling something like "Does this happen in the next scene, or fifteen minutes from now?").
• DO NOT be afraid to say something negative, if you can get away with it. If the studio bothered you somehow, say so. If the actor was half drunk, go ahead and say so. Obviously, the commentary track should not be a whine tasting, and you need to consider the potential other costs rationally, but this is your best chance to say something to your True Fans, and we like a little bit of dirt sometimes.
• DO NOT include multiple commentary tracks unless the tracks add value; I recall here the American Pie commentary track with a few of the actors, which largely consisted of the actors laughing at their on-screen antics, a sort of small-audience laugh track. This does not add value. If a purchaser cares enough about the commentary tracks, then they care enough to want a quality track.
• DO drop me a line if you use this list in making a DVD commentary. ;-)

I just had pretty much the worst week ever at work, which accounts for my not posting anything this week. How bad? I just finally noticed today that I didn't post my Monday Iron Lute post.

I can only hope this week is better. Unfortunately, it doesn't show any particular signs of improving, so posts may be slowed up this week too.

This week instead of continuing on with my outline series of posts, I think I may jump ahead and discuss the file format for my outline model, which is what I'm working on right now. Designing a file format to hold the data hasn't been too hard, but it's been a bit of a brain bender trying to figure out the best way to implement it. There are a few interesting things you can do with an outline structure you can't do with a conventional flat file, and I want to make sure that those things are possible. What day this will get posted, I don't know, since I still have to write it.