Instead of spreading the show over multiple posts, I'm going to try something new and put all of the videos in one post. Hopefully it makes for less clicking.

Enjoy, and merry Christmas!

Tommee Profit - O Come O Come Emmanuel

I really enjoyed this rendition of the song, which itself has always been one of my favorite songs of the season.

Selena Gomez - Winter Wonderland

This is one of the sequences I had in last year's show. Winter Wonderland is one of my wife's favorite holiday songs, so I decided to bring it into this year's show as well.

Pentatonix - Hark the Herald Angels Sing

New in the lineup this year, this was a request from my family. While it's great to do songs I like (and I did plenty of that!), I do the show mostly for other people, so listening to what they want to watch is fun.

Laurie Berkner - Jingle Bells

Another request, this time because it's my niece's favorite rendition of this song. This is also the only song I personally sequenced and didn't adapt from a sequence I purchased; I so far have done one per year. I'm looking to do more sequencing for next year; I just had my hands full with the hardware what with the new house

David Foster - Carol of the Bells

I enjoy this rendition of Carol of the Bells, as may be evident since it's another carry-over from last year. While I really like the song, I may look into a different rendition next year.

Ariana Grande - Santa Tell Me

Not gonna lie, I heard this on a Spotify Christmas playlist and enjoyed it, so I hunted the sequence down. However, I did quite a bit of modification once I downloaded the sequence; it's probably the most customized purchased sequence I have!

John Williams - Harry Potter Medley

This was one of the more popular sequences from last year, so it earned a spot in this year's show. I mean, it doesn't hurt that John Williams is a genius, and the sequence was designed by one of the better sequencers in the hobby: Tom BetGeorge.

I've been asked a few times how the system works, how to create a new display, and other questions about the tech behind the light show. In response, this post will be an overview of the system, giving a bit more detail about how everything works together. For those starting out, this isn't really a step-by-step guide since your own tastes, budget, and display area will be different to mine, but it should give you enough perspective for a good start on your own display.

For a broad overview of what components there are in a display and what roles, they play, I wrote a post which fills that role. It's been a while since I posted it, but the content there is still relevant. I'll be going deeper on the concepts I presented in that post, so if you feel lost or want a primer first, feel free to check it out!

Note: this is going to be a long article, so get comfy!

Props

There are a total of 49 props on my house of various sizes and shapes:

• 15 stars, each with 90 pixels
• 4 22" spinners, each with 85 pixels
• 2 36" spinners, each with 193 pixels
• 4 windows, each with between 70 and 102 pixels
• 3 permanently installed runs on the eaves, with a combined 602 pixels split over 8 props
• 16 other house outline runs with a combined 658 pixels

All together, that makes 4080 pixels in this display. That's fewer pixels than I had last year, despite having a larger house (and is also something I'm going to remedy for next year :-p)

When it comes to the data and power connections into and out of the props, there are two different categories of props which describe the connections therein: shapes and lines. While I am not going to get hyper detailed about each of these (I'll make a post about each type, how I wired them, and why I did so), I'll go over some basics.

Shapes

In this display, these are going to be the stars and spinners, but also applies to the arches, peace spikes, tombstones, spiders, and spider web from other displays/occasions). As a general rule, there is one plug for power for every 300 pixels in the prop, one plug for data in for every 600 pixels in the prop, and one for data out; these numbers are due to the capacity of the controllers and power distribution boards I use. Making the plugs as generic and modular as possible allows me to relocate the props without having to change the wiring based on where it may lie in a signal port's run (more on ports later or in this post).

In all cases, the data in and data out plugs only carry data and DC-; all the DC+ comes from the power plugs. I do this to ensure the highest amount of modularity for the props; since you shouldn't connect DC+ coming from two different fuses, and power ports each have their own fuse, isolating the DC+ to a single prop is the easiest way to prevent issues. This adds a small amount of complexity and, frankly, annoyance since it's possible to drive multiple small props (like the peace spike) straight from the controller without power injection; however, I decided that being consistent requires less thought while setting up the system at the cost of running a bit more cable.

As for the backing material, most of them are made from corrugated plastic (called coro) from various different vendors. When you purchase them, they come with holes for the pixels already cut into them; all you have to do is install the pixels and wire them up. The downside is that this is what most people do, so when you see displays, you can see the Holiday Coro stars, the Boscoyo spinners, etc. Personally, I don't have the patience to design my own props, so I will continue using the prefab coro blanks, but one can buy coro on their own and have it laser cut, and sometimes the companies selling these prop blanks will do custom props for people if they ask.

Lines

These are customized to specific parts of my house, so they are optimized more for installation and removal rather than for isolation from each other. To that end, I do power injection wherever it's convenient, share DC+ between sections when I can, and generally try to minimize the amount of cabling which has to be run.

Many of these are made from PVC, which takes a lot of time since you have to drill the holes for the pixels yourself. I drilled 1,688 holes for my display this year, so I'm very familiar with how much time this takes. However, the plus side is building props from PVC - especially for the lines around your house - is that they are very easy to install due to using PVC clips which screw into your house, they store really easily if you have the room (above my garage door is where mine will go off season) and the pixels end up looking very lined up. Further, since PVC is somewhat flexible, you can follow some curves or make curved props like arches relatively easily.

My eaves are built using vinyl J-channel and installed in such a way that they will be up year round. I wrote this post on the subject a while ago

Cabling

I use two completely different types of cable in my display: signal and power. The cables themselves are considerably different, the ends are completely incompatible, there is generally no confusing the two. This makes it very easy to determine where the power is going and where the signal is going at a glance, and completely eliminates the possibility to connect a power cable to a data plug or vice versa.

Data

The data cables I use are all assembled by the manufacturer and is ready to go when I receive it. I generally receive 4' lengths and 10' lengths which I combine as needed to run from controllers to props or between props. For longer runs (more than two 10' lengths), I'll install a signal booster between the last part of the long run and the prop. However, since the booster requires DC+ and, as mentioned before, I don't pass DC+ out of props, the signal booster will only work between the controller and the first prop; therefore, I have to make sure I don't do runs longer than ~20' between props because I can't boost the signal and it could deteriorate across runs longer than this. Personally, I'm using the xConnect brand of cable ends for pigtails on the props or on the prefab cables I buy; nothing wrong with other connector types, these are just the ones I purchased first and there's no reason to change.

Power

The power cables I custom build from bulk 12ga or 14ga two-conductor wire and Muyi connectors. I built a bunch of 4' and 10' lengths to match the data cables I have, but power injection is different. Whereas data cables are a single line and each input has one output, power can branch off multiple times with no problems (technically this is what happens at each pixel too); therefore I have had to create a ton of tee junctions. These junctions have one input and two outputs so I can have a line which branches at each of several props, one tee at each prop. I've built a bunch of standalone tees for generic use, but also have built some whole cable assemblies with multiple soldered tees for specifically placed props. I built all of those at my old house (believe it or not, it was faster to build these assemblies than the individual tees) so the spacing no longer makes sense for my current display.

I mentioned earlier I built a bunch of 4' or 10' lengths, but I also have several much longer cables (30' or more) using 12ga for less voltage drop. These are handy because you can have half as many pixels on a power port as on a data port, so you end up running twice as much power cable and it's easier to build one long cable which reaches way over there than several shorter modular cables. A good mix of each is a good idea too.

Pixels

I use exclusively 5V RGB pixels, though I may use 12V if I build some really high density props since 12V requires less power injection. Generally, I build props with the pixels and leave them in until I decide to completely scrap the prop, so even though I have fewer pixels this year, I purchased about 1000 more pixels for building props this year. I've bought from Ali Express and the Alitove brand from Amazon and there doesn't seem to be a major difference in quality. On the other hand, there is a difference in color, both of the wire and of the pixels themselves, so if you buy from multiple sources, you should be careful about mixing and matching.

For building props and getting the pigtail ends onto the props, I use solder seal connectors. I cannot sing their praises enough. They're easy to install and provide a reasonably durable connection, doing both weather sealing and soldering of the wires together. I probably shouldn't, but I regularly shove a 14ga and 22ga wire into each end of the blue connectors and they seem to hold up well.

Power

Virtually all of my show runs on two Mean Well 300W 5V power supplies, both the power to the pixels and the controllers themselves. There are many manufacturers of these and I'm sure they're fine, but Mean Well is a known high-quality brand, so I tend to go with those. The only things which don't use the 5V output from the power supply are the Falcon Player and the FM transmitter; those are both plugged into the wall. I have the Pi and the rest of the show on two different outlets of a dual smart plug so I can leave the Pi on while turning the pixels and controllers off during the day (the pixels conflict with the garage door opener radio, so I want them to be off as much as possible).

There are two Falcon F8 Distro power distribution boards, one per power supply, which take in 5V (or 12V) and spread it across 8 5A fused ports, each of which is capable of driving about 300 pixels (50mA per pixel * 0.3 brightness coefficient * 300 = 4.5A if all pixels are at full white, which they virtually never are); these are what do the power injection to the lights.

Control

There are three major components to the control system: the Falcon Player, the pixel controller, and the smart receivers.

Falcon Player

This is the main driver and coordinator for the show. Falcon Player is an operating system and piece of software which is capable of controlling multiple pixel controllers, as well as coordinating with other Players to synchronize larger displays. While it can be used on many different single-board computers, I'm using a Raspberry Pi 4b with 4Gb of RAM. Its responsibility in my show is to do the scheduling (which playlist should play at what time), content management (songs, sequences, playlists), and playing the song in time to the sequence via the audio out. I can use its web interface to control the playlists and playback and to configure the controllers it communicates with. In my case, it's a single controller, the Falcon F4V3.

Controller

As was just mentioned, I'm using a Falcon F4V3 for my show. Its responsibility in my show is to receive the sequence data coming from the Falcon Player and split it into signals that are sent out over each data port. It natively supports 4 ports, but I also have the expansion card which extends it to 12 ports using smart receivers which are connected to the F4V3 via ethernet cables. Each port can send data to up to 680 pixels running at 40fps, or up to 1024 pixels at 20fps; I generally try to keep it to 600 or fewer pixels per port since that means each data port on the controller (and smart receiver) gets two power ports from the power distribution board for a 1:1 controller-to-distribution-board ratio. The main controller is where I configure how many pixels are on each port and, optionally, configure each individual prop on each port for testing purposes; this would allow me to, say, reduce the brightness for high-density props separately to the rest of the show.

Smart Receiver

Smart Receivers are essentially remotely controlled followers to extend the number of ports available on a controller while also allowing the board to be physically closer to the pixels. Since a show can spread over large areas, positioning a smart receiver closer to distant props means you only have to run an ethernet and AC mains power to a box containing a smart receiver, a power supply, and a power distribution board, rather than 4 ports of data cables and 8 ports of power cables over long distances. I have two of these, the max that can be controlled by the F4V3.

Sequencing

All of my sequencing is done within xLights, which is a fantastic piece of software for designing shows. For the most part, I purchase sequences from various different websites, including rgbsequences.net, showstoppersequences.com, and magicallightshows.com. I also browse through the free sequences from xlightsseq.com and a dedicated Google drive for xLights sequence sharing. I also use xLights to define the various models which drive the props on the house, assign the models to ports, etc.

Miscellaneous

FM Transmitter

I have a cheap transmitter that accepts 3.5mm audio cable and transmits the incoming audio over a radio station that I can configure. The signal is acceptably strong; there's virtually zero distortion or static when watching the show from the intended areas, and the signal falls off after a block or two so it doesn't disrupt things too much. There are controllers which have a built in slot for an optional FM transmitter (Kulp boards, for example), but this has been working fine for me.

Weather Boxes

I am using the large boxes you'll typically see around irrigation to hold the various electronics. They're mounted to the walls under my eaves so they are not quite as likely to get water in them. I drilled vent holes in them with the intention of adding hoods, but then I never added the hoods, so I taped over teh holes, my reasoning being it's cold when the show is running, so the components are not in danger of overheating.

Outdoor Smart Switch

I'm using a Kasa Outdoor Smart Plug with two sockets which I have connected to Home Assistant; using the automations, I turn the power to the pixels and controllers on at sundown each night, and leave the Falcon Player on perpetually.

Wrap Up

Overall, there are a lot of moving components to my system, but it looks more complex than it actually is. For the most part, each port is duplicating the others; the props and models may be shaped differently and have different numbers of pixels, but the concept and how they get connected are all identical. As the show grows, it will necessarily butt up against limits which will require more complex expansions, but again, the concepts and execution will be carbon copies of what already exists.

From here, I'd like to start a series wherein I get more detailed about each of the props and equipment I built to highlight some of the limitations and decisions which were made along the way. Eventually, this will culminate in a full wiring diagram for the show. For the meantime, thank you for reading this far!

Now that we're in a new house, redesigning basically the entire display is going to be necessary. It's a bit of a bummer that this has to be done so soon after designing the last display, but an evolving display was always in the cards, so that evolution is just going to be a bit more... aggressive this year!

However, first things first. We really enjoyed having the "permanent" lights up on the roofline for the previous several years, so we want to have that again. Perhaps something a bit more... polished? Something that looks a bit more like it's meant to be permanent? I guess there's nothing wrong with just draping 2" PVC pipe over the gutter, but we have EXPERIENCE now; we can do better than that!

I've been reading a bunch about various different methods of installing permanent lights on the roofline, so lots of different thoughts and approaches. However, three are really worth considering, in my opinion.

First, one clarification. I say "roofline", but I want something that looks a bit more polished and is generally kinda hidden and out of the way. At the last place, the white PVC blended well enough with the white gutters and trim, but you could still see all the pixels and, while it wasn't bad, we can do better.

Thus, the goal is to install the lights on the inside of the fascia with the lights facing downward, just peeking out past the fascia. Note that we don't have soffits, so the rear of the fascia is totally open. By installing this way, when the lights aren't on, they're almost invisible. This mounting also has a couple side benefits, the biggest one being that the lights are out of the elements; they won't be rained on, will be somewhat protected from the wind, and won't get direct sunlight.

So, let's talk about installation methods. As mentioned, there are four opions, and we'll go through them each.

First, there's LED strips with aluminum channels and diffusers. These generally look really good and polished since they are intended to be more visible. Also, due to the higher pixel density (sometimes much higher) animations and transitions look smoother, an effect which is enhanced by the diffuser. However, there are some things I don't like about them. First, power injection is a bit harder. It's not hard, but it requires soldering and stripping back some weatherproofing, then adding hot glue and heat shrink to make it weatherproof again. Second they're harder to repair; replacing a single pixel in a string is easy; in a strip, it's hard. Third, I haven't had much luck with the adhesive in them, so they could end up flopping around in the channel. Finally, not much room to run power injection wire in the channel to begin with.

Since strips themselves don't seem to be great, let's look at LED bullets. Using bullets (pixels, whatever) is familiar to me, and I know how to handle them, so that's a plus. Also... I have a bunch, so I don't have to buy more, which is a huge plus. Therefore, the next three options will use pixels.

Option 2 is using LED bullets with Permatrack. Permatrack is a purpose-built product for mounting these bullets to a house permanently. It seems to be simple to mount, has a channel for running wires, and - importantly - has predrilled holes for the pixels at a good spacing. They also look fantastic. This would provide less time from purchase to installation because I wouldn't have to build a jig and drill several hundred holes, and could be easier to install. However, this is the most expensive bullet mounting option, coming in around $4 per foot before tax or delivery, so let's keep looking.

For the third option, we can use PVC pipe and clips for the same. PVC is cheap and I have a bunch of it from the display last year, along with some clips. I'd have to order more (or print some), but they're not break-the-bank expensive. The main complaint I have with this method is the wiring is all out and not protected since the hole and bullet goes all the way through the PVC pipe (we're talking like 3/4" pipe). Since these will be behind the fascia, it's not horrible, but it just feels a bit unfinished. Also, drilling a straight line in a PVC pipe without it  curving is... tough.

The option I'm looking to go with is using J-channel. This is usually used at the end of vinyl siding up against windows and doors. Generally, it's fairly decorative, so it will look a bit better. Also, the J-channel will give a kind of cable raceway to add a bit of protection and tidiness to the cable runs. Since the J-channel has slots for the screws to go in, it's easy to make mini adjustments to the fit and finish, even after a screw has been installed. And finally, the flat bottom of the channel is a bunch easier to get a consistent line out of. J-channel is about $2 per foot, delivered.

So, now that we have that settled, I just need to buy the J-track, spend an ungodly amount of time drilling (checks notes) over 600 pixels, do some wiring to allow for power injection and all that, install the lights into the J-channels, and then install the J-channels. EZPZ. That is a problem for future me!

It's been a busy winter! While setting up and running the show for Christmas, we were busy buying a home in Benicia, about 60 miles north from San Jose. As of April 2022, we are now in the new home and have sold the San Jose home. Exciting!

Since the previous name of the light show was directly tied to the street, a change of name is warranted. Wicked Fox is inspired by our last names and we've used it in a variety of contexts, so it feels natural to use it here as well. That way, if/when we move again, we won't have to change the name of the website or anything.

Glenmont Lights is dead! Long live Wicked Fox Lights!

The last post was all about controller ports, but didn't get into what a controller is, why you would want one, and how it fits into a light display. Now seems like a decent time to cover that and, more broadly, the various components which you can find in a moderately-sized display. So let's get into it!

To simplify things, you can think of a light display as equivalent to a person playing a piece of music on a piano. Or a person running a play in a sport. Or a person dancing. I play music, so I'm going to stick with the piano metaphor. With that in mind, let's start with the music.

Composition

At the very beginning, someone composes a song. The song can be simple, or it can be quite complex, but it will take into considerations the limitations of the player and of the instrument and may go through many iterations before it's just right.

This is the sequencing software used to generate the sequence which is later played; xLights is a common program and has been discussed here before. Taking into consideration the design of the layout, the number of lights, where they are placed, etc., you program them to make patterns animated over time, the end result being a file which can be passed to the next step.

Instructions

Once a song is composed, the composer writes down very detailed instructions on how to play the song, using a notation familiar to musicians; this is known as sheet music. From here, the sheet music can be distributed to musicians who wish to play the song themselves. They may change it a little based on their own interpretation of the song, add their own flair, modify it to match their capabilities and instrumet, but the general idea remains.

When you save a sequence in xLights, you end up with a sequence file which serves the same purpose. This can be distributed to other people who can then use it in their own display. Of course, you can modify the sequence based on differences in display, preferences of colors or timing of patterns, or because you felt like doing something different with the megatree, but the base sequence will remain.

Playing

Once a musician has the sheet music, she reads through it to get a better understanding of how to play. While reading it, her eyes and part of her brain are translating the notation which is written on the pages into sounds, intensity, patterns, and chords, and is also starting to get an idea on how to physically play it. When she decides to sit down at the piano, an additional part of her brain starts to tell her fingers, hands, and feet how to move in order to recreate that which is written on the page.

Just as there are two things going on in the brain, so there are two different components in a light display. The first component is a player, probably something like a Falcon Player, which translates the sequence file in the previous stage into some form of meaning. The second component, picks up that meaning and starts telling the lights how to flash. This component is called a controller, and the one I'm using is a Falcon F4V3. All the lights are plugged into the ports on this controller (or an extension board with differential receivers; kinda like having a brain in each shoulder as well as one in your head) and all the on/off/color change information for every light is distributed from this component.

Blood and Nerves

In order for our musician's fingers to move, her muscles need two things: commands on how much and when to flex or relax, and energy to power the muscle's movements. The commands are sent from her brain to her muscles by way of her nerves, and the energy is contained in blood moving through her blood vessels.

Both of these jobs are done by wires in our lighting display. The information about how to light up is sent via data or signal cables which end up connecting to the controller discussed above. For power, DC voltage is needed to make the pixels actually light up. In a smaller display, this can come from the same port in a controller, but is likely to come from a separate power distribution board, which we'll talk about next.

Power

In our musician's body, blood takes energy (in the form of glucose) and nutrients around the body, among other things preparing the muscles for activation by signals from the nerves. While many different parts of the body can affect the blood (lungs add oxygen, small intestine adds glucose and nutrients, etc.), the heart gets the credit for pumping the blood all around the body, distributing it to everywhere blood needs to be.

A power supply and, potentially, a power distribution board do the work of providing power to the lighting display. While there may only be a port or two used on a controller, we may have many distinct wires from the power distribution to the pixels due to the need to do power injection. The supply, distribution board, and wires are designed together to ensure that enough power gets to all the pixels which need it.

Instrument

Finally, we are at the point where the audience can appreciate the music our musician is playing. The fingers are controlling the piano, pressing down the correct keys as loud and for as long as the specifications say, creating music which comes out.

Of course, the last part of our lighting display is the most obvious one: the pixels themselves, arranged into shapes or outlines. Using the signal and power which are fed in, they light up different colors tens of times per second, enticing people to stop and watch, to oooo and ahhhh.

Summary

Like a musician, our lighting display is very complicated, but with a fairly reasonable number of understandable components. Hopefully this has been a helpful view into what goes into a light display and helps take some of the mystery and scariness away.

Building props that will be powered by a controller like the Falcon F16 is as easy as attaching pixels to a structure, connecting that string to the controller, connecting the controller to power, and boom; you can do the test patterns on the controller!

Well, unless you want to use more than a certain number of pixels in the run, in which case you need to add more power somewhere along the line.

Um, also if you intend to power more pixels per port than the 5A fuse allows.

Or if you just have more pixels than the port can update per cycle.

Let's look at what's going on here.

Light displays like the ones we're building are fairly complicated electrical circuits, and like any circuit, there are limits to their capabilities. For the purposes of this post, we'll be looking at only one of these circuits, one string of lights coming from one port; let's call this a run.

Some of the things which limit a run are the same as with other circuits: fuse(s) on the circuit (there's usually one built into the board per port), wire gauge, and wire length. On the Falcon F16, the ports have a 5A fuse, so we can't pass more current than 5A through this run without blowing the fuse. Wire gauge and length is.... complicated, so we're going to ignore it for the time being.

For typical LEDs, the amperage of each RGB pixel is approx 60mA, or 0.06A. This suggests that we can run about 83 pixels on each port, after which point we risk blowing the fuse on the board.

This is where things start getting.... weird. If you plugged in a string of 83 pixels and put them to full white (100% brightness to each red, green, and blue pixel), you'll notice that they look fine... up until around pixel 50 or so, at which point, they start taking on a pinkish hue. Virtually nobody would consider the color the 83rd pixel is emitting "white".

The reason for this dimming is because of a phenomenon called voltage drop. As you go down the line, each pixel consumes a little bit of power, which reduces the amount available for each pixel further down the line. This is fine in the beginning as each pixel has more than enough power to work with; a 5V pixel will work fine down to about 4V, for example. After a certain threshold (somewhere around 50 pixels), the pixel is unable to fully power all three LEDs, and thus they each have a lower brightness. There's a bunch of charts and models you can look at to get a richer understanding, but all you need to know is that this is a thing.

So that's two limits: how many pixels a port can provide power to (83 or so) and how many pixels with good color rendering a port can drive (50 or so). Let's assume that neither of these is a problem. We'll just avoid physics and say that any number of pixels can be powered without melting the board, and further assume that voltage drop is not a thing. We still will have limits to how many pixels a single port can drive, but this time it's how many can be updated every frame.

"Frame" is an animation term, hearkening back to the French "framêz" which means I'm kidding I did literally zero research into the history of this terminology. I'm pretty sure it's from photography (a photograph is a frame contained by the borders of the photo) and then was adopted by movies, which are just 24 images per second being shown to you to give an illusion of moving pictures. In animation, particularly in computer animation, it's a moment which is frozen in time, where some controller or artist has defined exactly what the display should look like for that very brief moment.

This is how pixel displays work. Many times per second, the controller tells every single pixel what color it should be, waits until the next update time, then tells every single pixel what color it should be again. Frame rate simply means "how many frames are shown over time" and is typically measured in frames per second. Refresh rate is directly related to this, but it typically describes how much time elapses between each refresh (frame) of the display and is typically measured in milliseconds or thousandths of a second. Common frame rates are 20fps and 40fps; the former has a refresh rate of 50ms and the latter has a refresh rate of 25ms.

Back to ports. Each port can only update a certain number of pixels in a given refresh rate time period; this is due to each pixel taking a tiny bit of time to take its portion of the message and pass the rest down the line, the speed of light (how fast the signal moves through the wires to the next pixel), and built-in overhead on the controller to determine what the next frame is going to look like. My controller (Falcon F16V3) can update 1024 pixels per port every frame, but only when running in 20fps; if I want 40fps, I have to drop my pixel count to around 600 pixels since the controller won't be able to keep up.

Fortunately, we can solve for two of these three main limitations. We can't do anything about the maximum number of pixels a single port can update; that's physics and computers and stuff, and it's pretty damn impressive that a controller can update 600 different tiny microcomputers (which is what LED pixels really are) across my front yard 40 times every single second. However, we can fix the much more restrictive limits of 50 pixels and 83 pixels by using power injection, and we'll get into that with the next post.

One thing I've found very helpful when building props is to write down various notes about wiring. Sure, there are going to be some rules or guidelines you should follow (e.g. DC+ goes to DC+, how to manage power injection, etc), but what wire colors are, what connectors you use, whether the male plug is on the incoming side of the prop or on the outgoing, etc. are going to vary based upon your preferences, the types of components you buy, etc.

To add to the difficulty, sometimes this stuff is not very well documented. For example, for the pixel strands I bought there is no documentation as to whether the signal goes from the male plug to the female plug or vice versa; you have to figure it out on your own.

Thus, writing these things down is incredibly helpful. By doing some preliminary thinking and design work, you can simplify the process of wiring and reduce the possibility of bad wiring quite a lot.

You won't have to go back and figure out what you've already done in order to try and match it. It's annoying to have to get a fully wired and functional prop out of storage to figure out which direction the current is flowing, which direction the plugs should go, etc. Further, if you always use the same practice for wiring things up, your system is more flexible and open to changes without having to rebuild connectors, etc.

At a minimum, these are the things I would write down:

• Which wire colors carry what type of current. Do this for pixel strands, other prewired props which need to be connected, signal cables running from the controllers to the props, and power injection.
• What direction connectors face. I find it easiest to think of this as "incoming" and "outgoing", but it's also commonly referred to as "upstream" and "downstream" (controller/power source is always "outgoing" or "upstream"). As an example, if you buy the Ray Wu connectors, it's common to wire the female plug (holes instead of prongs) to the controller connectors which plug into the board. The direction doesn't matter as long as it's consistent.
• Which wires go to which connector poles. This is useful mainly for power injection wires, but it really depends on how in-depth you get with your wiring.

That's seems like very little, but do each of these for each of the wire types and it starts getting to be a bit of info. However, I promise that you will appreciate having this when you go months between building props and have completely forgotten which way everything goes.

For me, it ended up looking something like this:

As for that last bit about not connecting DC+ to signal cables? I'll get into that soon when I cover power injection.

In my post about model grouping, I mentioned that one can have nested groups of models. One might want to do that if there are several groups of one type of model, then another group which has all of that model. I found an issue with how this works and am going to put a big caveat on using nested groups.

For example, on my house, I'm planning to have five stars on my garage and five stars on my house. I would like to be have the option to control them separate to each other, so I have "Stars - Garage" and "Stars - House". However, I also want to control all the stars together, so I want "Stars - All"; that way any time I add a star, I just add it to one group (say, "Stars - House") and anything group that has that group nested (say, "Stars - All" or "House - All") will automatically know about that new model.

However, this has a limitation during sequencing. When you apply effects, there is a "Render Style" option. In this, the default is to use all of the models in the group as a broad canvas onto which to apply the effect.

However, you also have the option to tell it to apply the effect to each of the models under the group (one such value is "Per Model Default"). This is useful when you want to have, say, the same starburst effect on all the stars without having all the stars on the timeline individually and applying the effect to all of them. I touched on the differences in the model grouping post. The end result is the same as if you'd applied the effects individually, but the same exact effect will be used and kept in sync.

The limitation is this: if you have nested groups, the groups which are nested will be rendered as a group instead of the individual models. Here's an example using my "Stars - All" group (hey now, I'm an All Star...). For illustration purposes, I have both individual models and a nested group within this group so you can see the differences.

This is using the Default rendering on the top-level group. As you can see, the explosion goes out from the middle of the group and passes through all the stars. Let's see what happens when we change the Render Style to Per Model Default.

That's interesting, right? As you can see, each of the stars on the left bursts within the star itself, while on the right, the burst renders across all five stars. That's because the stars on the left are added to the group individually, whereas the stars on the right are added to the group within a nested group.

So we come to the crux: I am going to go back and, in many cases, change my groups to hold only models. In the long run, it is going to be a bit more maintenance as I add new models, but hopefully that'll be only like once or twice a year. However, with things on which I intend to never use Per Model Default rendering (e.g. my EVERYTHING group), I'll just keep with the nested groups, because damn are they convenient!