Yes, you are understanding things. Where you might be getting confused is the understanding that
fixture addresses are not exclusive and multiple addresses can be assigned to single control channels/dimmers through soft patching. That is, if I have an
LED fixture that uses 10 addresses to control all its functions, I can have more than one
fixture set to the same
address and control both when I change the value of that
address.
Soft patching can be tricky to get your head around at first, but a lot of that is the terminology. In your case, where you say you have all fixed lights with (I'm assuming) a
dimmer per light, you can set your
console or software to have
channel/slider #1
send its value to any one of a number of
dimmer addresses. This is how many of us have a slider for "Area 1" that is lit by lights in dimmers 1, 4,and 26, for example.
That's
clear. It's very similar to how a number of common paradigms are implemented in software, which is my main professional undertaking. I was more interested in knowing if there are any boards that can
page the faders when you do have a need for more channels than your board has faders. At this
point, I'm convinced that faders are not the great asset I might have thought they were. Selection by keybad and setting by wheel/trackball seems more facile, particularly when one might want to set more than one
channel:
3 [THRU] 8 [AND] 23 [ENTER]
followed by manipulating the trackball has some obvious advantages over trying to shove seven faders (not all of which are near each other) around, synchronously.
BTW, the
Enttec Open, although a good device, will not control a lot of channels without stuttering in my experience. It uses the driving PC for the timing signals for
DMX and therefore requires a more powerful computer to control more lights. The Pro has its own internal
processor for timing and will give you better results in the long run.
I've read about this, here and there. That shouldn't happen. A lot of "real time" software suffers from Windows's default power-saving settings. When your program is "blocked" (that is, not doing anything because it is waiting on input, or for an output operation to finish), Windows will slow down the CPU, sometimes to a bare fraction of its full speed. Upon becoming "unblocked," (that is, reacting to input, or picking up again after an output operation has finished), it can take up to 40 milliseconds for Windows 10 to decide that full CPU speed is justified. During this interval, very inconsistent behavior can be observed,
provided that the 40 ms time-frame is long compared to what you are doing. (On modern computers with multi-core CPUs, it is even more inconsistent, as not every core will
return to full speed at the same moment.) Now, 40 ms is a very interesting interval in the context of
DMX 512, because a full-length
DMX 512 frame has 513 bytes in it, with each byte being eleven bits long (one start
bit, eight data bits, two stop bits). 513 times 11 is 5,643.
DMX 512 is sent at 125,000 bits per second, meaning that a full-length frame takes 5,643 / 125,000 seconds, which is .045144 seconds, or about 45 ms. An inconsistent
return to full speed could sometimes be long enough to miss a full-length frame and require waiting for the next full frame.
However... the worst that should ever show as an
effect is a delayed change, not a missed or incorrect setting. Not all device drivers work the same way, but I note that
Enttec's literature on its Pro model emphasizes an "internal frame buffer," to "preserve data integrity when computer is busy." Well, in the
driver I have, a shared
block of memory is read continuously by the
driver, and sent in a full-length frame, as often as possible. The timing is driven by the speed of the
DMX protocol, meaning that a new frame is sent every 45.144 ms (plus a few microseconds, which are meaningless, compared to the 45.144 ms time required to
send the frame). The
console software shares that
block of memory with the
driver, writing settings to the 512 locations that--each one individually--control the values being sent on each of the 512 channels. Unless the
console software writes an incorrect value there, this scheme can be a frame late, but it can never
send a value the
console software didn't supply.
Now, if someone tried to get more complicated and
send frames only when a
channel's value changed, it's possible that the speed-management of the CPU could fool a
driver into thinking all changes had been made when they hadn't, and therefore into sending a frame with some zeroes in channels that shouldn't have them. But that would simply be a
bug in the
driver, imho.
I write real-time video software (at 30fps, a frame is about 33ms for me, so I'm used to working in this regime). Until I discovered the CPU-speed issue, I was tearing my hair out over some inconsistent "stutters" of my own. Simply disabling all of that and running my CPU at full speed made absolutely all of that go away. (There is a vaguely related problem arising from the original IBM PC's inability to time anything to a finer granularity than 1/64th of a second, an interval 15.625 ms long. That can cause some stutter of its own, but modern PCs can (if you ask them to) set a granularity of 1/1000th of a second (1 ms), and almost everything (Google's Chrome browser is a notorious example) asks them to. In an extreme case, a program can just "spin" and never
block, allowing timing to a granularity near the microsecond range.
I'll look into this further after I have the device. Writing my own code for it sounds interesting.
As for adjusting the levels when asked for "up a
bit", what I did in my software was use the keyboard arrows for +-1, PgUp, PgDn for +-10, and Home, End for +-100. The
mouse wheel will also change the levels up or down. I would figure most consoles have the same ability.
What software are you using? I downloaded DMXControl and, though it's not open source, I can see already why faders aren't the answer to my needs. It allows a variety of setting methods, but being able to click on an icon and just
roll the
mouse wheel is proof enough that I don't need faders at all.
(For my
OCD programming colleagues: Yes, transmission of a full
DMX 512 frame takes longer than 45.144 ms, as there must also be the "off" interval that signifies the end of a frame. I don't believe that makes any difference, but I acknowledge that it exists.)