Posts by Soon5


    Same there. Same issue.

    Also DMXControl 2 is written in VB6, where Microsoft canceled the development support already 12 years ago:…port-for-visual-basic-6.0

    Right now, we don't even have a working development environment running for the DMXControl 2 series. The Software is as it is and there won't be changes or enhancements.

    Even if you find somebody taking a look into the binary files, that person will also have to spend a couple of hours to get that "Move things around" program working without breaking anything. It is questionable whether overall that is really a time save if you take that persons time into account.



    I want to wrap up the discussion for you a little bit.

    You have currently two choices on the table:

    1. Purchase a Hardware DMX Merger and a DMX Controller as boneshaker suggested and do everything in Hardware. The financial damage will be about 150 Euro for the Merger and Controller

    2. Purchase a DMX Interface that can be connected to a computer with DMX-In and DMX-Out. You connect your Foot Controller to the DMX-IN and your lights to the DMX-OUT. That way you have full control on which DMX-Lines go where. In your case I would simply cut the 1st DMX-Channel and only forward the Channels 2-... and control channel 1 (the dimmer) with the software DMXControl. The Software ist free of charge, the cost for the Interface similar to the Option 1, but the advantage is, you can use DMXControl to do way more with your lights then you can do with your preprogrammed Foot controller. The disadvantage is, you need to have a laptop included in the setup, which I don't know if that is what you want.

    Remark regarding the DMX Interface. There are Interfaces on the market that have an HTP Merge function Build in, so they can inside the Interface mix the DMX-Stream from the Computer with an external DMX-Stream like your foot controller. Personally I don't see the advantage of doing so if the Software supports reading DMX-IN Information (like DMXControl does). Maybe the reason some Interfaces support this is that some software doesn't support using DMX-IN.

    So, now it's up to you to decide which way to go. If you choose Option 2 and have more questions, don't hesitate to ask them. You can also try out the freeware software (DMXControl 3.2.1) we are offering at before taking a decision.



    I think what boneshaker is suggesting is the easiest feasible option. On the other hand, if you need to invest in an Merger and in an 1ch Controller, maybe you purchase an ArtNet or USB Interface and start working with DMXControl as your lightning software :-D with potentially way more options. I don't know what your usual setup is and whether working with an Notebook in addition is a good or bad Idea.

    Hello. Sorry for the very late answer.

    We found that issue, it will be fixed in 3.2.2. At least that error Message is solved. Whether that was the root cause of your problem, you have to test then.

    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:

          <Attribute Name="Value" Type="Primitive" ValueType="String" Value="False" />

    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.



    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.