Posts by Soon5

    Just out of interest, why would a DMX to RJ45 Adaptor have a different pin assignment than the standard DMX variety?

    The basic issue starts with the amount of Pins. An RJ45 has 8 Pins, an XLR3, so there are obviously some not connected, or combined as in your case Pin 7 and 8 are both GND. Sadly there is no official standard how the 3 DMX Pins are mapped to the 8 RJ45, so out there is a wild variation of adapters and combinations as every vendor is doing whatever he wants.

    Well, I don't know that there is any standard on how to convert from XLR to RJ45, so from the shape the adapters are correct, but whether the connection mapping is correct, nobody can tell from the picture. So yes, you need an adapter like that with the proper wiring which matches the imprint on the controller.

    It's true. So far, the Colorwheelrotation and also Gobowheelrotation are not stopped, in case a fixed Color / Gobo is set. This is currently the intended behavior, so there is nothing wrong with the DDF. Nevertheless, we can discuss whether this behavior is the right one. As Stefan mentioned, we can have the discussion in the Team.

    hy Scott.


    Yes if you add the Setting everything in Programmer will be saved by default. And no you dont need to adapt in case of an update.

    That's perfect if it does

    Unfortunatelly it doesn't. When you open the Filter (not pressing shift), you see that only the Values that have changed since the last save are ticked, only those will be saved. All the Shift button does is omit the Filter, it's like directly pressing OK without changing anything. So if you set 300 in the 1st cue, all of the 300 are saved. If you then only change a few and save again, only the values of those few will be saved.


    EDIT: There is actually a global setting that you can change to disable this behavior. Unfortunatelly it is not available via the UI. You need to find the "GuiConfig.xml" file in the DMXControl Profile Path, open it and add a Setting:


    Code
    <TreeItem Name="GUI.PROGRAMMER.TRACKED_PROGRAMMING">
    <Attribute Name="Value" Type="Primitive" ValueType="String" Value="False" />
    </TreeItem>

    From my perspective it seems like an unnecessary flag

    What's unnecessary from your perspective is required for others. The Flag is not there without a reason it's because we had other cases where users requested it. That's why the flag is existing.

    the default should be checked

    You are free to configure all the Defaults for all of the Flags on a Cuelist, Project and Application level, so it's up to you to just do it.

    Maybe a little bit more explanation on this behaviour and the difference in Tracking / Non Tracking.


    In Tracking Mode, each cue fades in new Values with the Fade time defined in that cue. So the existing values are overwritten by the new ones, new ones are added. Untouched Values stay as they are.

    In Non Tracking Mode two things happen.

    1. New Values are added / overwritten similiar to "Tracking" Mode, so here also the new cues fade times apply.

    2. Old Values which don't exist in the target cue need to be faded out. Here per Default the values are simply rolled back with the same fade value that originally wrote them. This is the reason why in your case there is a difference when you jump from 1 => 3 vs. 2 => 3. To enforce using the same fade / delay timings as the Target Cue, the "Tf" Flag is used.


    Hopefully this helps.


    Regards


    Arne

    It's easy. You just have to set the "Tf" Flag in the Target Cue.


    This Flag means "Take Fades" which actually indicates that this cues Fade / Delay Timings overwrite the "Source" Fade / Delay Timings.


    The Behaviour makes sence because this way you can decide whether you want to apply the Target Cues Timings or the Source Cue Timings.

    yes, please provide the project.


    My assumption is it works if you set Tracking to true and explicitly set the other lights to 0% in Cue 3.


    Not having looked into the code my assumption is that due to not having a "fade out" time for the Cue 2 Values, the Fade In Time is reused.

    I have a counter question. What is the reason you want to build that kind of spot's yourself? Is it "just 4 fun" because I imagine that when you sum the costs of all the pieces together you can also purchase off the shelf LED Floorspots.

    I am asking because if I am looking ahead, planting all of these LED Modules in the housing and taking care of the thermal management will be a challenge. Unless this project has also a DIY component included I doubt that this makes sence.


    I am just asking to get a better understanding of where this all should lead to.


    Answering your question, normally LEDs don't have a reflector in the shape of the work Lights, the lens shape is cone shaped and you have multiple of these. I think your best try is putting 3 of these inside the housing with a 30-60 degree Lens and not use the original reflector. Nevertheless 9 Watts is still not very bright. Also the 3 Watts is per Module, which means the individual color is less. You only have 3 Watts if you run these modules on "Full On" mixing RGB and Whites.


    To give a comparison, the "small" Eurolite PS-4 HCL Spots I am using (https://www.thomann.de/de/eurolite_led_ps_4_hcl_spot.htm) have 4x12W which means, each LED Module has 2W per Color in total 8W per color. As mentioned I consider these spots small so you can use them in groups or for small areas if it is not to bright. I would not go for less wattage if you really want to use them as light source.


    Regards,


    Arne

    They are show with an "Error", if the XML Structure is invalid. If the XML Structure is fine but there is something wrong with the values a Detail Dialog is displayed if you try to add the device. Nevertheless if you are unsure, you can upload the DDF here, so someone else can try and we rule out whether it's a DDF issue or not.

    Since I think 3.1.2 we seperated the DDFs that we "Shipped" and the ones the User adds by himself into seperate Folders. This is due to the write protection stuff and also it helps us keeping the Shipped DDFs up-2-date as we can simply overwrite them.


    So your root cause was you tried to put the files into the wrong folder.

    Hello,


    Where did you try to store it? Did you use the Link to the DDF Folder that was created by the Installer?


    The DDFs should be placed in the Profile Path which should not be write protected.


    Regards


    Arne

    Moderator comment: I split your two replys into a seperate thread, as the other one was about DMXControl 3 and yours is about DMXControl 2.12