Color picker, walls & control spaces


The project I'm working on has a space that has several (8) sub spaces that can be combined to a single space or to different combinations using walls. Each supb space has a lot of RGBW lights and the customer wants to control them in groups and in seperate channels. The idea is that the controller in a sub space controls the lights of the sub space and also the sub spaces combined to it with open walls.

The faders work fine when the control space is set to the sub space where the controller is, but the color pickers don't follow the control space. I can change the color of a single channel even though the walls are closed


  • The controller sits in the sub space A and it's combined to the sub space B through a wall AB. The control space for all the faders and color pickers is set to sub space A. The wall is open and everything works as expected.
  • The wall AB is closed. Group and channel faders and group color pickers of the sub space B work as expected (= do nothing), but I can still adjust channel color pickers of the sub space B! Is there a workaround or a more clever way to achieve this?


I wish there was an option for faders and colorpickers, that when they're not controlling anything they would be invisible. Like when the wall is closed to the next room all the controls of the room woud vanish from the UI. Visibility groups are too limited for a project like this with so many different combinations.



  • Hi Ike, without seeing your configuration it's a bit difficult to say for certain what the cause of your issue here is, but what I can say at the moment is any button, fader, or color picker control is going to function on the target object in the Control Space defined on that control. So even if a touchscreen is located in subspace A, if the target control is scoped to subspace B, it'll still control that object even if the wall is closed. The touchscreen (or any other station) doesn't care which space itself is located, just where its controls are targeted to.

    Something else to consider is keeping your touchscreen targeted to objects in subspace A, and using Combine Name to control other subspaces when the wall is open. That reduces the overall quantity of "stuff" you have to program on the touchscreen, but also prevents control of other spaces when the wall is closed. Take a look at this support article (make sure you're logged in!) for further details on the topic:

  • Hello again,

    I got finally some time to demonstrate what I mean.


    The setup is four spaces combined through four walls. Each space has two RGBW lights and a touchscreen.


    All the faders and color pickers are scoped to the space where the touch screen is, so when the walls are

    open the user can control all the fixtures of the combined space individually. No problems here, but…


    When the walls are closed I can still adjust the colors in all spaces and I shouldn't! The faders and the group color picker work as wanted but the individual channel color pickers don't. I can also the the intensities with the color picker in wrong space.


    Check the attached file and see for yourself. The LD version used was 5.1.1


    Best regards,


    Color Picker Test.lcdconf

  • Hi Ikka, 

    You have only included the Control Designer File, could you attach your Light Desinger file should be a .pcf file.



  • I see what you are describing. The channel fader is working as expected but not the colour picker.
    Not sure if this is a bug or just as you are targeting a specific channel then Paradigm is jumping the space control space. I think Chris will be able to comment on that.

    A work around would be put the channels in groups and then it should work as expected.

    If you want to get clever then I would start doing things with visibility to completely hide controls when certain walls are closed so the customer can only see the fixtures they should have control with.
    It gets kind of complicated with multiple wall and multiple touchscreens but I can put together an example using the config you have sent through and email you an explanation.

  • Ok,

    The demo file is of course a really simplified version of the real deal with hundreds of RGBW lights, 12 walls combining 8 spaces and 7 touchscreens and more to come as I get ahead with the project. Total fixture count wil be over 1500, 36 Touchscreens and a Central Control Server with 5 bigger touchscreens etc.

    Making single fixture groups of all the color changing lights and rearranging all the controls will take hours and eat up the resources. I hope this is a bug that can be fixed.

    I've managed to use visibilities to hide controls in a different floor of the same project. It had only two walls, so using visibility groups worked ok. With this floor with 40320 different space combinations the three visibility groups is not the way to do it. Or maybe I understand the visibility concept the wrong way.

    I wish that all the controls would have a selector that if the controller can't control something, I mean if they are not in the same combined control space, the control would turn invisible. Also if the tab has no visible controls you can choose if you want the "empty" tabs be visible or not.

    Anyway, I'll take all the help I can, so please e-mail the visibility example.


  • So I think you might need to take a different approach to this problem. 

    I will email you an idea