Calibration of moving heads

  • Hello DMXControl users,

    I have recently started playing with this software and find it amazing; I am very happy with it. I am new to lighting and have tried some other softwares also.

    I did come across an issue though that may be a showstopper for me, and I imagine I am doing something wrong because the software is so well thought out.

    Here is my scenario:

    I have 4 moving heads, one in each corner of a room.
    I would like to calibrate them to the floor, and create effects where they can move in sync. Essentially I want to map them to a coordinate system of the room.
    They should be able to point to the same spot, and from there pan/tilt in sync across the floor. This would also facilitate fanning and effects.
    Another software I tried was PC_DIMMER, and it had such a calibration feature in the device settings

    How can I accomplish this in DMXControl 3?


    Here two examples; all pointing and following the same spot on the floor with pan/tilt movement, and the second one where they are fanned and following a circular pattern, for example

  • JPK February 28, 2026 at 8:16 PM

    Approved the thread.
  • Hi and welcome in our forum,

    currently (DMXControl 3.3.1) there is no mapping option available yet. So no, you don't do anything wrong. There is simply not the option for that yet.

    However: As a hint: Watch the upcoming livestream about the features of DMXControl 3.3.2 ;) (we already said, that there will be such a video in the nearer future but we did not released a date for it yet). But what I can make clear: The fanning option (your second image) will not be without some workarounds. But yeah, stay tuned ;)

    JP

    im Falle eines Falles klebt Gaffa einfach alles, denn Gaffa ist dein Freund und Helfer :thumbup:

  • Thank you for the quick answer and confirmation of the issue.

    - Do you know of a workaround in the current version?

    - Is there an RC version or Beta available for 3.3.2?

    I really like the DMXControl the best from all I have seen, but am not sure how to realize and coordinated movement given the mountings of the heads.

  • - Do you know of a workaround in the current version?

    As I said, in the current version of DMXControl (3.3.1) there is no such possibility. Also no practically way with some workarounds. You could maybe do something with the Input Assignment. But this will be ultra complex and a monstrosity of connectionset.

    - Is there an RC version or Beta available for 3.3.2?

    There is no publicly available beta version yet. If there would be one, I would have told you ;)

    I really like the DMXControl the best from all I have seen,

    Thank you :)

    but am not sure how to realize and coordinated movement given the mountings of the heads.

    Well as I said, wait a bit (maybe some weeks) and see, which features will be in DMXControl 3.3.2 ;) I know, it is hard to wait, but you need to be a bit patient until we complete our release process.

    im Falle eines Falles klebt Gaffa einfach alles, denn Gaffa ist dein Freund und Helfer :thumbup:

  • Hello, absolute beginner here...

    As I'm just starting with DMXcontrol 3 too and also checking other software and the function you need is not implemented so far, I think it is ok to mention that QLC+ 5 got this function. And there is a youtube tutorial QLC+ 5 - EFX explaining it at 12.00 min how to do ist. Maybe you want to have a look.

  • Well this is an option for sure. But as I said, it is more about weeks than months or years until we release the next version ;)

    im Falle eines Falles klebt Gaffa einfach alles, denn Gaffa ist dein Freund und Helfer :thumbup:

  • Thanks for mentioning QLC EFX; I have also looked into that.
    However, I really do prefer the DMXcontrol interface; the QLC just feels too tablet-like for me; I really don't like it much at all for anything other than the fact it has this feature :}
    The DMXControl way of making things happen is much more intuitive and logical (at least to me), so I'm hoping this will be implemented in the future.
    Unfortunately there is no core application source code on github to check the viability of submitting a patch :}

  • So as I said there will be a livestream (in German) soon about some 3.3.2 features. Here it is:

    The livestream is on Wednesday, April 22th 2026 at 8pm CEST

    im Falle eines Falles klebt Gaffa einfach alles, denn Gaffa ist dein Freund und Helfer :thumbup:

  • Apologies for the late reply,


    I finally had time to look give the position mapping in 3.3.2 a cursory look and must say it is already fantastic.
    The implementation via the mapping is so elegant because it allows to use multiple or no mappings!
    This is already a great step; I hope in the next version the position fanning will also work.

    Thank you very much; this wait was well worth it!

  • One more follow up question as I was playing with that:

    is it true and correct that a Pan/Tilt Fanning (Like 0>90) for a Position Mapping with 3 heads will not spread them across a wall?
    I.e. I understood correctly that it is not implemented/by design?

  • is it true and correct that a Pan/Tilt Fanning (Like 0>90) for a Position Mapping with 3 heads will not spread them across a wall?
    I.e. I understood correctly that it is not implemented/by design?

    This is actually the same problem as with the position fanning. Both are not implemented yet and we are trying to find a way to implement that. We tried to find this way already on our annual club meeting two weeks ago. But all tries failed so far. The issue is that a fanning is only broken down to every device, if the fanning is applied to a group. If it is applied to a device, the first fanning value is taken. Thus, at the point I am doing the mapping calculation I only get a single target value (for a single device) and not the whole fanning. Thus we need to find a way to get both worlds. But this is not so easy.

    However, what you can do is to create multiple Position Mapping devices and map only one moving head in it but all on the same area. Then you can put those Position Mappings into a group and then you can apply fannings onto this group. So this is currently a (not so convenient) workaround to get the fanning working.

    im Falle eines Falles klebt Gaffa einfach alles, denn Gaffa ist dein Freund und Helfer :thumbup:

  • Thank you for the cursory overview of the underlying issue.
    What is the purpose of being able to apply a fanning to a single device? Are there any useful scenarios or just a byproduct of the logic?

    I suspect there was a very good technical reason for this, but:
    Why is the position mapping implemented as a device rather than a device group?
    Maybe when creating a position mapping it should create an automatic "shadow group" that could be used to apply the fanning? This should be analog to the workaround of multiple mappings inside a single group.

    I am not super familiar with DMXcontrol or DMX in general (new to this and only as a little side thing), but it seems to be possible to apply different fannings to device groups containing the same devices (like overlapping fannings).
    These fannings are then somehow merged into the last edited group, is that correct?
    In that case such a shadow group might work (as multi-group spanning fannings are already handled in "some way"), but I am not 100% sure how these overlapping/conflicting fannings are merged.

    Does that make sense or it is too obscure to understand what I'm trying to say?

  • Why is the position mapping implemented as a device rather than a device group?

    The general intention is, that you can have multiple position mappings in your project. A second aspect of the "device-implementation-solution" was, that there already exist a similar work flow with the Color Bridge (mapping device) and the Generic Matrix (mapping device).

    But regarding you question: it's indeed a good question and related to the work flow a valid propose. But here I can't give an answer if there have been any limitations, because I am not inside the development team.

    These fannings are then somehow merged into the last edited group, is that correct?

    If you give values to the same function of only one device from different sources, like the device itself or different device groups, it's about the priority and the merging setting of the related cuelists they want to send the values. So DMXControl 3 is able to handle this situation generally.

  • Hi,

    It seems like the device group or "shadow mapping" could work as the workaround does the exact same thing. A device group would also allow for multiple position mappings because I could still create multiple groups with the same devices, and the group could have the "Patching Field", no? Maybe there is something I am missing internally as I don't understand or am familiar with the core architecture.


    Regarding the merging, I meant only in the stage view/programmer.

    - Create 3 devices 1,2,3

    - Create 2 Device groups (Devs 1,2 and Devs 2,3)

    - Create a fanned position in Group 1, then Group2. Switch back and forth and only one groups has a superposition of all.


    I have attached a sample project and a steps recorder PDF. I somehow cannot record a video in the VM...

  • Hi,

    Maybe there is something I am missing internally as I don't understand or am familiar with the core architecture.

    I am sorry to say this but in short: Yes, you do ;) Thank you very much for your thoughts and I really appreciate that you try to help :) But without knowledge of the code it is almost impossible to present a working solution for this problem ;) And even with knowledge of it (the founder of this part of the software was in the team which tried to implement the fanned mapping) every solution we tried did not work as intended. I can assure you that we (obviously) know the internal structure and yes, we also tried the way with groups. There are reasons, why the Position Mapping is a device and why the way with groups did not work as planed. As I said, we will work on it again in the future and try to find a better way.

    im Falle eines Falles klebt Gaffa einfach alles, denn Gaffa ist dein Freund und Helfer :thumbup:

  • Okay, I trust it will be made very good and obviously cannot understand the code without having looked at it.
    I know the feeling when you are the author of a code and fail multiple attempts at modifying something :}


    But I think you already figured out the actual problem - and solution.
    - A position mapping (as a device) logically should only represent a single device: allowing a single mapping represent multiple devices will likely cause other unintended side effects in addition to only getting one fanning value
    - Your workaround of one mapping per device and then grouping the mappings is actually how it should be (imho).

    The best (abstract) solution might be:
    - Allow only a single device in a mapping (1 to 1)
    - Use device groups (manually created as with normal devices) to fan and do other things with position mappings
    - Modify the calibration dialog to allow showing multiple mappings at the same time if desired (as it shows all devices in a single mapping now) : This would allow calibrating them all at once, as it is now

    This would retain the proper structure (separating devices and groups) and thereby not break fanning or other logic, allow the convenience of calibrating multiple mappings/fixtures at once, and still allow multiple different mappings to be used on a single device.