In the options menu, how is the patch across universe boundarys set?  The default is on which would explain what you are seeing.

Yeah, this is due to the way Capture have implimented the "Patch fixtures across universe boundaries". It literally just continues the fixture across the two universes.

Obviously for traditional fixtures this doesn't really work, as we're generally using a copper 5 pin cable to get the signal to the fixture, and no fixtures are able to receive data even if you did find a way to mush it on to a single data + and data - pair.

This is mainly aimed at having larger pixel based installations or custom pixel tape fixtures, where you can only get 170 RGB pixels on each universe, but there are controllers that will receive multiple universes over artnet or sACN, and output that as a single pixl data stream, allowing much longer runs and more efficient cabling.

If you turn off the "Patch fixtures across universe boundaries" option in the universes tab, and then repatch the fixtures, it will patch them in the way you want them to be.

Personally I think that option should default to Off, otherwise it will make a mess more often than not.

I also think the default setting should be OFF.

You can change the default behaviour for any new project via the Tools menu - Options - General - Project Defaults. 

Hi, it is not about not being able to change the behaviour. It is about what the software does out of the box. The behaviour everybody expects and needs, unless you use very specific fixtures (which are the minority by far of the current fixture stock out there), is NOT to patch fixture across Universe boundaries.

Agree with this. The behaviour immediately after installation should be as intuitive to the user as possible. This cross-universe patching is not something that most people are going to need in any traditional lighting scenario. By default on installation this should not be an enabled feature. It's position and accessibility are fine, but it shouldn't be the default state.

This is also a default behaviour change at the same time as introducing the feature, as prior to 2026 there was no cross-universe patching, and the existing "continue patching until finished" would patch fixtures on multiple universes in a traditional way.

Hi, I faced the same issue, patching a big amount of RGB led strip fixtures, MA3 fills the universes and start patching the next available fixture in the next universe,Example: last RGB fixture patched as 21.508, next one will automatically be 22.1.

Capture go on filling all the available parameters splitting a fixture in two different universes Example last RGB fixture patched as 21.511.It means this las fixture is splitted between universe 21 and 22.Phisically it is non possible.

Let me know if I'm missing something and there is a solution cause the option I found is to calculate the lenght of a strip of 170 RGB fixtures maximum to fill 510 dmx parameters but it's very annoying.

The option exists. It is just not the defalt setting on first boot of the software.

What complicates this all slightly is that with this option off it's not possible to patch multiple fixtures that require more than 512 channels at once.

That means that anyone who has been waiting for support of modes more than 512 channels would immediately find themselves in a problematic situation.  On the other hand if you patch multiple "normal" fixtures and they span a universe border you will understand what is going on, perhaps post here and learn how to handle the situation.

Also, when surveying the situation in lighting consoles we discovered that the default behaviour in a couple of consoles (I just don't remember which right now) is to split fixtures across universe boundaries. We can only assume this comes as a result of it becoming more common to run ethernet to your fixtures, in which case patching a "normal" fixture across a universe boundary is quite handy.

We also just introduced the generic LED fixture that can easily consume more than one DMX universe.

Now if you don't use huge DMX mode fixtures you're not going to be impressed by this answer I guess, but at least you'll know why we did what we did.