Help with pixel mapping (TD and LeDMX4 Pro)

I’m trying to map 5 (it’ll be 10) bars I made, each has 120 pixels. Lighting everything up from TD (1 universe per bar) looks like this:

The first bar/universe 0 is mapped properly, but then between each following universe there’s a gap of 50 pixels, so universe1,2,3 are off spread between bars and universe4 (last bar) is not even showing.

Settings on eDMX config seems to be ok. 600 is the maximum RGB pixels one output can run so 120x5.
Start Universe can’t be 0, so 1 relates to universe 0 on TD. Null Pixels is 0.

Here’s the fixture mapping (using Karl Skene amazing TOE):

Each bar is set to 120 pixels, as well as the shuffle splitting the values each 360 channels (120x3).

I’ve run out of ideas. Does anyone know where the problem can be or where to look at?

On the same topic but smaller issue I couldn’t solve. I have a height offset between the TOP and the mapping:

I’d like to adjust that back to 1:1.

This is fixed now.


It depends on how you wired your bars with 120 pixels each and on how you are planning to split the DMX universes

A couple of things to check.

On the LeDMX4, to run up to 680 RGB pixels per output you need firmware 3.1+.

Each DMX universe is made of 512 channels.
Based on their documentation, it’s my understanding is that the LeDMX4 can send up to 16 universes, 4 universes for each port.
680 pixels x 3 (RGB) = 2040 channels per port
2040 / 512 = 3.98 aka 4 universes per port

The second thing is that after your shuffle CHOP, you need to make sure that the data is packaged in a way that the pixel board (in your case LeDMX4) can understand, and the pixel board needs to be set up to send data in a way that the pixel bars can understand.

About the DMX universes.
If you have 120 RGB pixels, you will occupy 360 (120x3) DMX channels for the first bar (in universe 0). That means you have 152 DMX channels left in that universe (512 - 360).
152 divided by 3 (RGB) makes 50.6, that might be why you have that strange offset of 50 pixels?

After your shuffle, you need to make sure that the data is packaged correctly, one universe per bar as you mentioned. You can leave those last 152 values “empty”, physically there are no pixels in your bars to receive that data.
Packing up each universe to its maximum (512, or 510 to be precise for RGB pixels) could be done but it usually results in a much more complicated cabling. It’s quite normal to allocate one universe per bar, without using each universe in full, and keeping the cabling as straight forward as possible, in case you need to extend the cabling, moving the bars around etc…

My guess is that you are you are trying to control all bars from one port, sending all universes out of port1? this is probably why you have set a pixel count of 600 out of port 1 (120x5 = 600).

If that’s the case, since you have 5 bars, there is a fair bit of calculations on how to split 4 universes onto 5 bars. It’s possible but the cabling and calculations involved could be confusing.

I would keep it simple and send one universe to each bar, as you mentioned.

You could try: port 1 to control bars 1,2,3,4 , and port 2 to control bar 5.
And then when you will scale up, port 2 to control bars 5,6,7,8, plus port 3 for bars 9,10

Set port 1 and port 2 to pixel count 480 (120x4), and port 3 to 240 (120x2).
Keep that pixel count number always updated to the number of pixels you are using.
The LeDMX4 does its own data packaging and will send data out according to those settings (pixel type, pixel count, null pixel and color order).

If all this doesn’t work (it does conceptually, but I don’t have a LeDMX4 here with me right now to do some tests), you could also try to pack each bar “back to back” in your shuffle CHOP splitting every 510 in case the LeDMX4 sends out data that way out of each port and your bars are daisy chained.

I hope this helps!
if it doesn’t let us know and send a screenshot of your shuffle chop, the dmxout settings and the dmx routing table (DAT).

1 Like

Hi @FaustoB,

Thanks a lot for reaching back :smiley:

Definitely was trying to run 5 universes out of one port, big mistake. Removed one bar to simplify things for now, just map 4 bars.

To simplify feedback, here’s the TOE
LiveSet_Lights.154.toe (414.7 KB)

What I get after changing the pixel count to 480 on LeDMX4 is the exact same pattern as before: a gap of 50 pixels or a duplication of 50 pixels (depending on the CHOP connected to DMX out, on the Karl Skene TOE “shuffle2” or “rename2”), and the bar 4/universe3 not showing any changes as pixels are all taken.

I’ve noticed one thing: as you can se on the picture, this is what happens lighting up the second bar/Universe1 (same with the following universes), there’s ‘contamination’ on the previous universe for whatever reason.

Captura de pantalla 2021-11-24 a las 13.36.04

So in order to change this I’ve tried setting “Pattern2” length to 360 instead of 510, to cut the number of channels. As expected, the ‘contamination’ can’t be seen but the 50 pixel dupe still shows on the bars.

Also tried setting one DMX out per universe but got the same result.

I do believe the problem is there, the ‘contamination’ seen on “rename2” is the duplication of the first 50 pixels of that universe. Linking “Shuffle2” to DMX out instead, those 50 pixels have no values, but they are still sent offsetting the mapping, thus the differences I’m experiencing, but still can’t find the place to hunt down those 50 pixels.

Wanted also to mention that “LedDetails” DMX channels per universe and pixels per universe parameters are not linked to anything so changing them do nothing, I took the original TOE to compare but it’s the same. Only important parameter is pixel per strip as it changes the split value on “Shuffle2”.

Captura de pantalla 2021-11-24 a las 14.14.08

Thanks again, Fausto!

Hey Carlos,

I am not fully familiar with the pixel mapping you are using in your network. It seems a great technique, but probably a little bit overly engineered for 10 bars of 120 pixel each.
I had a look at it, I can see something odd going on but I could’t find the source of the problem.

Have a look at the file below.
LiveSet_Lights FB.toe (14.7 KB)

On the left I have made a base container with a pixel mapping technique similar to the one I use. You can find this technique in operator snippets DMX out.
I have adapted it to match your scenario and reused some of your network to rebuild the dmx routing.

On the right I kept your LED_mapping Base that I was trying to fix. Everything has been bypassed though to avoid conflict between the two dmxout CHOPs.

It’s all made in blind as I have no way to test it right now, but I am fairly confident that it should work based on the output I see in the network and in the dmx out CHOP.

1 Like


The network you shared is indeed more straightforward to understand, thank you.
However, the problem still persist, same absent 50 pixels at the beginning.
I’d need to flip upside down each bar pair since the daisy chain is made from top to top and bottom to bottom, but not needed to see that the problem is still there.

This makes me think there’s a problem down the line, being LeDMX4 or the bars. I’ll start troubleshooting the bars to check there’re no bridges between pins, I’ll make a fw update to LeDMX4 too and write to them if needed.

By the way, I was automating crossfades between TOPs to blend animations using a MIDI CC and its inverted copy to opacity on different level TOPs, meaning I needed a CC coming from Ableton for each pair of TOPs, complicating the set in both Ableton and TD. Just saw your Switch with ‘blend inputs’ activated, didn’t know it was THAT easy. I can remove all this mess every two TOPs for just one operator for the whole set, thanks for the inspiration :smiley:
(each Select is a MIDI param)

So, thank you again for the help. At least we got to discard (most probably) the mapping problem. I could try to map on other software but that’ll take more to learn than start troubleshooting the bars.

I’ll keep posting here what I find, hopefully someone can learn from my mistakes until I fix it.

The problem is that you are splitting the LED strips into a seperate LED strip per universe, but the DMX King is expecting the universe splits to NOT be at the start of each LED strip. In fact the DMX King has no clue how long each LED strip is so it is just joining all the DMX universes together and sending them out.

Each universe you are sending out has 360 DMX addresses with interesting data in them and then the last 152 DMX addresses of each universe are just zeros. Instead of having the Shuffle CHOP split by 360, you need to have it split by 510 because that will fill up the whole universe with data.

I say 510 and not 512 because 512 does not divide evenly by 3, so you would only be able to send the first 2 values of the next pixel and the 3rd value (usually blue) would get cut off. The DMX King knows this and only uses 510 values from each DMX universe - unless you were to do 4 channel LEDs (aka RGBW or something) in which case the DMX king would be able to divide 512 by 4 equally and send out 128 pixels of data instead of 170 pixels - which is the number of pixels you can fit in one universe of DMX.

That’s where the extra 50 pixels are coming from. You are sending out 120 pixels of data to each universe and the extra 50 pixels between each universe are being assumed and sent out as zeros, hence the 50 pixel gaps.

TLDR: set the shuffle CHOP to 510 instead of 360 and it will work for reasons.


@Verbose exactly what Peet said. My example was assuming you were sending data to the strips by each individual port on the LeDMX4.

On top of changing the Shuffle CHOP as Peeet said, it’s important how the strips are daisy chained in your set up.
If you go top to top, bottom to bottom, you need to have your line SOP and copy SOP to reflect that pattern.
If you right click on the copy SOP, select Display option, and then activate Point Numbers you will see what I mean. All the pixels in each bar start from the bottom going up.
These points need to match the pixel layout, which in your case is “zig zag”.
From memory the LeDMX could be set up to output data this way, but depending on the situation I tend to prefer to set up TD for zig zag scenarios.

Play around with a transform SOP or with the Copy SOP to achieve the pixel layout that works with your set up

1 Like

@Peeet, @FaustoB, can I invite you to a beer or a coffee?

I can’t believe it was that easy, my motivation was gone thinking about disassembling the bars.

So yes, both methods I have work now splitting at 510 channels, of course yours too Fausto.

I’ll keep the FixtureMap base because it’s easier to arrange them, at least I got used to it.
Flipping bars around is more straightforward and actually got that right from the start.

Thanks again for the solution and the actual explanation, I can continue with the setup now :smiley:

I’ve tried with 6 bars now (3 per LeDMX4 output) and the second half is giving me problems.

So, the first 3 bars work like a charm but not 4, 5 and 6. Settings are exactly as the first 3 bars, sending 510 channels per universe and LeDMX4 set to 360 pixels per output (outputs going to bar 1 and 4). The offset I have now is 10 pixels (instead of the 50 before) and I can ‘correct’ it by adding 10 null pixels at the start of bar 4. It makes the mapping correct but there are 10 null pixels on bar 4 of course, so it’s not ideal.

Shuffle chop (or split table) seems not to be the issue here and tried other things without good results.

Any ideas what to check?

I’m afraid this will be the norm adding more bars to the setup using different outputs. At least I expected them to behave the same having the same settings, but unfortunately that’s not the case at least I’m missing something.

You might need to put an additional Shuffle CHOP in before the CHOP that is splitting it every 510 samples. You want to fill up the universes (510 samples) but you also want to split the data into what should go to each output first (360 pixels aka 360*3=1080 DMX values) so in this instance if you put a Shuffle CHOP in that splits 1080 samples before your shuffle that splits 510, I think it will work, but it’s hard to tell where the “10 null pixels” are coming from since even without that first Shuffle, I think it should be off by 20 pixels, not 10…

Attach a screenshot or a copy of your latest file if you can’t figure it out, but I guarantee it’s some combination of shuffle CHOPs that will get you where you’re trying to go…

1 Like

I’ve tried a few combinations and the universes are all messed up. Can’t figure it out unfortunately.
Attached the latest file, additional shuffle is not there for clarity. Thank you again.

LiveSet_Lights.216.toe (595.3 KB)

I had a look at your network and arranged the universes to match your set up.
Let me know if it works.

LiveSet_Lights.216 FB.toe (12.2 KB)

FYI I am not sure if it was intentional but the last 3 line SOPs in your fixtureMap corresponding to the last 3 pixel bars were all inverted by 180 deg. I have set them to match the 90deg and 270deg alternating pattern to make it easier for me see what was going on.


Thanks Fausto, checking it right away :slight_smile:
The rotation was intentional since I’m using the 4 leftmost (finished making another bar) and the 3 rightmost pixel bars for now. That’s why the pattern was changed there.

Edit: LeDMX4 has stopped working for no apparent reason while checking the file, so I have to halt anything lights until I get it fixed or replaced. No power, no output, no ethernet, no on-board LEDs, it’s dead. I wonder if these things are under warranty…

Are you running power for the LED strips THROUGH the LeDMX Pro4? You should probably make sure to only have a path for power directly to the LED strips from the PSU and have data and ground going to the little connectors on the DMX King. Obviously also power going to the DMXKing’s power input but not hooking the hot line from the LEDs to the DMXKing, just directly to the Power Supply.

As long as it is all on the same single PSU you should be fine, but the DMXKing can only handle 5A per output of power going THROUGH it which adds up quick especially if you’re doing 5V LEDs. Unfortunately unlike the Advatek stuff there are no fuses (that I know of) so if you were trying to power all these LEDs at once through through the device itself that might be the culprit.

Also the 5VDC DMXKing dies pretty quickly if you give it 12V as I have discovered :frowning: twice :frowning:

1 Like

I was powering all 7 bars (so far) with two outputs. Did the math and 5A (12V version as Fausto suggested a while ago) is a little short for 4 bars at full power, but having tested them I see no issues by doing so, at no point in the set I have full brightness in white for all bars at once. The pixels are quite strong even with the diffusor, so opacity is never 1 (tested at full darkness).

I have additional power outputs from the main PSU and a secondary one in case I need it.

So, I had to send the unit back to the reseller in France. Le’s hope they can fix/replace it.

It’s up to you but don’t go tight with the power supplies!
I’m not an electrician but I recommend to always have headroom in power supplies, and fuses wherever needed.

If that’s ok to say, the bars might look bright in a small studio for testing, and never go at full brightness, but once they are on stage perhaps with other competing lights (or in a gallery, or outdoor, or wherever they’ll go) it’s possible you might have to go at full brightness.

1 Like