More pixels per NDB

[cswales]

Not critical -
Could assign more pixels per ndb in the fixture files by setting up two outputs that happened to point to the same ip address. Apparently this is totally legal.
(Would be pretty easy to test manually on site, by just replacing one ip address with a copy of another one)

[mcslee]

Confirming that output packets with the DDP protocol are structured as-defined in LXF files. LX will not attempt to do any merging or splicing of DDP.

If you say: output: { protocol: "ddp", start: 0, num: 10000, ... } it's going to make a 10000-pixel packet (this will not go well!)

If you say:

outputs: [
  { protocol: "ddp", start: 0, num: 10, ... },
  { protocol: "ddp", start: 10, num: 10, ... },
  { protocol: "ddp", start: 20, num: 10, ... },
  ...
]

Then you're going to get a lot of 10-pixel packets. Should work fine but probably not the best idea.

Point is - it is completely up to you guys to format your output definitions to whatever level of grouping and packet size you prefer.

[cswales]

Yes, I think the idea was to have more than one packet per NDB. I think the packet size right now is limited by the UDP packet size on the wire, and right now we're limiting ourselves to just one packet, which is considerably less than the NDB is capable of. Tagging @bbulkow for verification

[bbulkow]

Realistically, we already have all the NDBs we need in the trees, and this isn't a big deal. It's a small deal though, because with this, we can map cubes anywhere instead of having to think through where the 1500 byte breaks happen.

And for anyone looking at this later, it's really hard to get a raspberry pi to output > 1500 frames.

[bbulkow]

This was recoded, and so it is likely that a given NDB will be turned into multiple outputs, but there is no attempt to limit an output. This code can now be changed likely pretty easily to limit. The limit should be (1500 - 10) / 3 RGB, because I think DDP has a 10 byte header.