Jump to content
Light-O-Rama Forums

Pixel Packers and the Universes


jstorms

Recommended Posts

Hi, my name is John Storms and I'm a pixel packer. Rather I was a pixel packer and now I'm reformed.

 

Many E1.31 pixel controllers allow you to easily configure DMX channels to wrap universes from one element/port to the next and to the next, and so on. So pixel packing was naturally the way to go.

 

Then I pulled up the updated visualizer and found that it didn't like pixel packing. It made it tricky when adding pixels and asked DevMike about it at Expo. He said pixel packing was stupid and to not do it. The discussion went back and forth and I was not convinced.

 

I had two misconceptions that kept me from seeing the light:

 

1 - Licenses by Universe.

I thought that if I ever upgraded to Madrix or some other universe based tool then I'll be screwed.

I have this fantasy that I'll win the lottery, purchase 150,000 pixels and go crazy with Madrix, but won't want to spend more than I need to on the software. Truth is that Madrix licenses by the universe, but they don't have to be contiguous. It is licenses on the number of channels in a certain number of universes, not by the number of universe numbers you use.

So no problem here, esp. since I haven't won any big lottery money.

 

2 - I was worried that I would run out of universes.

So looking at the spec for E1.31 and ArtNet I see the max number of universes is 64K-1, or 63,999 universes. Based on that, I think I'm safe on not running out.

 

Reasons to not pixel pack:

1 - LOR Visualizer will be your friend and DevMike won't call you stupid. Not that he would...

2 - Another reason to not pixel pack is what happens when you have an element that starts half-way through universe 6 and ends in universe 7, and you want to move it to a different controller. Obviously, you need/should to put it on a different universe, but then you have to renumber your channel configuration *facepalm*. 

 

So now I am a reformed pixel packer and will be using universe number judiciously. 

 

Oooh, but what about E1.31 traffic? It will increase my E1.31 traffic.

 

 

pantallazo-cosmos.jpg

Link to comment
Share on other sites

  • Replies 42
  • Created
  • Last Reply

Top Posters In This Topic

  • k6ccc

    7

  • jstorms

    5

  • dougd

    4

  • zvacman

    4

I have not found away around pixel packing if your using the e682 boards: ; which means a pain using the visualizer; it works, just more thinking involved, which is always painful

Link to comment
Share on other sites

I'm on the fence on that one.  I agree with wmilkie that with the E682, it is often unavoidable.  Also as an old school data-comm guy the concept of wasting bandwidth just seems wrong.  Since every universe of E1.31 results in about a quarter megabit per second of data being sent, sending extra universes is wasteful.  However, I'm sure very few of us are running their E1.31 over a 10Base-T link so for most of us bandwidth is not really an issue - unless you're using WiFi, in which case it COULD be.

 

On the other hand, in prep for some planned changes to my show layout for 2015 (that mostly did not happen), and because of the changes with S4, I made some major changes to the universe layout.  I only have one prop that includes packed universes.  Having to be a little creative to make it work with the E682s, and it increases my active universe count from 10 to 15.

 

My background still makes me want to not waste the bandwidth, but that part really is not an issue for me...

Link to comment
Share on other sites

I'm on the fence on that one.  I agree with wmilkie that with the E682, it is often unavoidable.  Also as an old school data-comm guy the concept of wasting bandwidth just seems wrong.  Since every universe of E1.31 results in about a quarter megabit per second of data being sent, sending extra universes is wasteful.  However, I'm sure very few of us are running their E1.31 over a 10Base-T link so for most of us bandwidth is not really an issue - unless you're using WiFi, in which case it COULD be.

 

On the other hand, in prep for some planned changes to my show layout for 2015 (that mostly did not happen), and because of the changes with S4, I made some major changes to the universe layout.  I only have one prop that includes packed universes.  Having to be a little creative to make it work with the E682s, and it increases my active universe count from 10 to 15.

 

My background still makes me want to not waste the bandwidth, but that part really is not an issue for me...

Oh, Yuk!    After reading this I'm thinking maybe I did the wrong thing..........(Just starting in pixels)  I'm doing a 32 string pixel tree with 50pixels P/string running on 2 controllers on E1.31......So what I did was create 32 universes with 50 pixels P/universe and using WiFi to send the data.

 

But after reading  what you just posted it sounds like I may have issues with lag (I think that what it called) meaning the lights won't keep up with the music, I that a correct assumption on my Part.

 

You guys are a lot smarter than me on these pixels, so should I go a different route? 

 

If so what do you recommend? 

Link to comment
Share on other sites

My first question is do you HAVE to use WiFi to connect your E1.31 controllers?

 

If yes, what kind of WiFi are you using - and I'm mainly interested in the technology (802.11a, vs, b, vs, g, vs n, vs ac), not the brand.

Are you using the same WiFi for your family stuff?

 

Are you using multicast or unicast for your E1.31?

 

That's enough for now...

Link to comment
Share on other sites

I have to put the tree across the street............I wanted to go up high with Cat 5  (like Roof Top to Roof Top)  But when I checked with the county the nixed  the idea big time.

 

I purchased a AC router with matching bridge (wifi extender)

 

I am using family stuff off this router also  but its on 2.4GH  and I put the pixel stuff on 5.0GH  This router has the ability to select instead of it selecting it for you .........I've all ready taken it across the street and tested it and my computer can see the controller but thats all the testing I've done so far with it.

 

I'm just starting to sequence with PE  ( Yes I know I'll never have it all done this season LOL) Just ran into too many issues getting this pixel stuff to work.

 

Oh...........I'm using unicast

Link to comment
Share on other sites

Understand the gotta do wireless in your case. And based on your answers, you are pretty much doing everything right.  You should be fine.

Link to comment
Share on other sites

Whew!..........Thanks for the reply, after reading this topic i thought i might have to start over and I've already done that around 16 times trying to get this thing going.

Link to comment
Share on other sites

It's not that pixel packing is stupid per se.  As with everything in life, there are trade-offs.  

 

I most definitely understand the want to save a few bytes here and there.  When I entered the professional world we were right on the cusp of 'Every bit is sacred' and 'Programmers cost more than bits' thinking.  At the time, we had to try to strike a balance - we couldn't expect to have unlimited memory/bandwidth/DASD, but we could expect to have a lot more than they did a few years ago.  If wasting a meg or two of storage meant that what we wrote made a heck of a lot more sense, we did.  The poor schlub that came after us to do maintenance appreciated the straight forward nature vs decoding some very unique programming to save a bit here or there.  Of course there are times I can't help myself but twiddle bits - just for old times sake:

    'The following are DEPRECATED in favor of the new definition below.    'When a board's configuration is loaded, bit 4 is checked.  If it is    '0 then this is the old style flag and it will be updated to the new    'style.    '00 = Undefined (Assume PACKED)    '01 - Simple 1 uid    '10 - Advanced 1 uid    '11 - 1 UID per port (Ignore UI mode)    DepricatedSimpleOneUIDPerPort = &H1    DepricatedAdvancedOneUIDPerPort = &H2    DepricatedOneUIDPerPort = &H3        'Low Nibble    'These are the new flag bits...    '1xxx = New Flag Definition in use    NewMethodFlag = &H8        '1xx0 = Unpacked    '1xx1 = Packed    PackedFlag = &H1        '1x0x = 170 pixels per port    '1x1x = 340 pixels per port    Pixel340Flag = &H2        '10xx = Simple Mode    '11xx = Advanced mode    AdvancedUIMode = &H4        'High Nibble    DontCreateNetPrefs = &H10

(and I still have 3 more bits!! :))

 

 

Pixel Packing is in many ways the same.  Right now we pretty much have unlimited bandwidth available to us for E1.31 applications.  Yes, it's a 1/4 Mbit/universe, but Almost all of us have at least 100Mbit networks, and many have 1Gbit.  LOR software can currently only handle 999 universes of data (call it 1000), which means at most we would consume 25Mbit.  

 

Let's assume we waste 50%, so 12.5Mbit.  Yes, it bothers me too:  Why would I want to spend $25 on something when I can get the exact same thing for $12.50?  Frugality/necessity your choice - 50% is 50%.

 

But then when you look at it from the perspective of time saved, things can change.  Assuming all things equal and that you have a choice between packing or not.  Is 12.5Mbit savings worth it to you to be up a ladder in -20 (F or C) weather:

 

  • Counting the number of pixels from the head end to where things are not working correctly and then doing some modular math in your head to save 12.5Mbit,
  • Or would you rather be able to look at something (probably from the ground) and immediately know - "That is Universe x"

 

That decision is not what really drove the decision on the Visualizer however.  When designing that, we had to make a choice between things being 'prop centric' or 'device address' centric.  Actually we need to look further back than that to the initial design of Showtime S1.  At that time there really wasn't a choice - things were arranged by unit and circuit.  Unit IDs would ALWAYS be 01-240, and Circuits would ALWAYS be 1-16.  Even today in the DMX world those concepts are still firmly rooted as the Universe and the Channel.  Knowing how all those things fit together shows that there really isn't a choice to be made:  The visualizer went with (and remains today) device centric.  

 

Naturally, I am not saying that device address is the ONLY way things should be done.  There are many valid reasons to go with prop centric ways of doing things.  The main one is of course programming.  Things like the Pixel Editor and SuperStar could care less how you divide things up between universes/uids, because they are fundamentally driven by a prop or props.  They can allow for those weird constructs.

 

Which brings us back full circle to packing or not packing.  If your hardware doesn't require packing (like the PixCon16), AND your programming environment doesn't care (Superstar/Pixel Ed), AND you have sufficient bandwidth (wired, 100Mb), ask yourself these questions:  

 

  • Do I REALLY want to be freezing up there on the ladder, or do I waste a couple of bytes here and there for simplicity?  
  • Do I REALLY want to manually move programming and/or redo channel assignments pixel by pixel should I care to make a change, or can I waste a few bytes, put stuff on it's own universe, and then move at will when needed?
  • Do I REALLY want to pull my hair out remembering what starts where and the need to physically divide stuff (like in the Visualizer), or do I go with some wasted channels/bandwidth?
Link to comment
Share on other sites

The last 2 years I was a pixel packer also. Every universe I used up all 170 pixels, 510 channels. So when I said I was using 40 universes, I was using 40 universes. This year as I was setting up the visualizer like you said, it didn't that method. It got me thinking why I was doing it also. This year  I will have close to 100 universes. SO much for the pixel packing days.

Link to comment
Share on other sites

I have 2 props that have 250 pixels run from a DIY LED Express Bridge and Pixel Extender. I have to pack those 2 elements. Since I was planning on running E682s this year, my sequencing started with packing the elements. If the Falcon boards work out this year, I wont need to pack them next year. 

 

It may be stupid to some people, but because of the limitations of the boards when I started my pixel changeover, I had to pack. Not everybody has the same situation.

Link to comment
Share on other sites

I do not want to pack. One element. One universe.

But the funniest thing ever happened. I ran out of universes. E682 has max number. Yes, I am in unicast but 16 plugs exceeds the max universes (12). And every plug is used. Forced to pack.

Boo.

Worse is I found out after the yard was up. Talk about scramble. (And poor planning). Working fine now though.

New controller on the upgrade list for next year......

Link to comment
Share on other sites

I was going to pack as much as I can in.

 

Infact I was going to run my whole display on a single output of a Pixlite4.

 

When I tried to use the visualiser I realised and redid all my channel configuration.

Link to comment
Share on other sites

  • 3 months later...

Another pixel un-packing milestone achieved! There are now, no packed-pixels in my configuration.

I have a pixel treeline of 13, 6' white twig trees with 125 pixels each (totally 375 channels per tree). Multiply this across 13 trees and you get 4,875 channels.

In 2014 I pixel packed these bad boys meaning that I went until I filled one universe (well upto 510, not 512) then started the next universe, right in the middle of whatever tree I was on. This made adding them to the visualizer a pain, but I muddled through it.

My pixel-packed treeline looked as follows:

Description Start Universe Start Channel Stop Universe Stop Channel
Tree 1 1 1 1 375
Tree 2 1 376 2 240
Tree 3 2 241 3 105
Tree 4 3 106 3 480
Tree 5 3 481 4 345
Tree 6 4 346 5 210
Tree 7 5 211 6 75
Tree 8 7 1 7 375
Tree 9 7 376 8 240
Tree 10 8 241 9 105
Tree 11 9 106 9 480
Tree 12 9 481 10 345
Tree 13 10 346 11 210

Note on trees 8-13 are on a different controller so I started with a new universe.

Now I'm in the process of cleaning up my configuration so it will scale nicely and I went through and unpacked these pixels. So instead of using 11 universes I now use 13. This will make it so I can make a nice and accurate fixture for my trees as well as make it easier if I want to move them between controllers.

Description Start Universe Start Channel Stop Universe Stop Channel
Tree 1 1 1 1 375
Tree 2 2 1 2 375
Tree 3 3 1 3 375
Tree 4 4 1 4 375
Tree 5 5 1 5 375
Tree 6 6 1 6 375
Tree 7 7 1 7 375
Tree 8 8 1 8 375
Tree 9 9 1 9 375
Tree 10 10 1 10 375
Tree 11 11 1 11 375
Tree 12 12 1 12 375
Tree 13 13 1 13 375

Instead of changing the 4875 channels by hand I wrote a PERL script that did it for me. Link to the script is [HERE] if anyone wants to look, but is custom to my configuration.

John Storms - pixel packing free

 

Link to comment
Share on other sites

For the cost of 2 'wasted' universes, you have gained not only flexibility, but ease of use.

You now know that when you have a problem with tree 9, it's universe 9, no thinking required.  If the problematic pixel is #35 of that tree, you know it is channels 103,104,105 with some quick multiplication that you can do in your head (35 * 3 = 30 * 3 + 5 *3 = 90 + 15 = 105.  105 is the last channel of the triplet, so 103 (105-2) is the first.

 

Link to comment
Share on other sites

Hi my name is the Grinch and I am a pixel packer. (Sounds like someone at some other type of meeting)

Its not by choice but because I have to.  I have a 12 CCR tree with a 4 Channel RGB Star on the top, I have a San Device E682  I can only get 12 universes in Unicast.

Is there a 12 step program to follow to get out of pixel packing? 

 

Link to comment
Share on other sites

3 hours ago, Grinch said:

Hi my name is the Grinch and I am a pixel packer. (Sounds like someone at some other type of meeting)

Its not by choice but because I have to.  I have a 12 CCR tree with a 4 Channel RGB Star on the top, I have a San Device E682  I can only get 12 universes in Unicast.

Is there a 12 step program to follow to get out of pixel packing? 

 

Yah get a falcoln lol

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

How do I avoid packing with an E682 running a 600 pixel matrix? The book says it is capable of running 680 total.  The math doesn't work without carrying strings over universe lines, I believe that is what packing is, right?  I only have 3 major pixel pigs in my show. The matrix, mega tree, and house outline with two big wreaths. I already have two E682's and WAS going to buy 1 or 2 more but now I'm considering a Falcon.  On the other hand I can buy two more DIY E682's for the price of the Falcon and add more flexibility to my layout.  If I were able to send the data 40-50 feet from the controller to the prop I would go Falcon in a heartbeat. Are there any tricks to doing that? From everything I've read 20-25 feet is about as far as I can go. Sorry for being so long winded but like previously mentioned this is kind of a support group for us.

Thanks, Z

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...