Rework log: DMX USB plugin asynchronous transmission

[mcallegari]

This is another rework I've done for the greater good. It's a bit technical, but the summary of it is: DMX USB devices should work better now, especially Eurolite.

The DMX USB plugin had a fundamental design flaw.
Looking back at the core timer tick diagram, it is clear that NOTHING should interfere with its work, especially because it has only 20ms to process EVERY component of the chain, either in the engine or in the virtual console.

DMX USB (and actually other plugins too) was the bad apple of the chain, performing serial operations (SLOW!) within a timer tick, therefore blocking it and the whole UI with it.
My fault I didn't realize this before, after so many "flickering" reports, frozen UI and whatsoever.

The key points are:

• the QLC+ engine timer runs at 50Hz, DMX runs at 44Hz. A miracle PRO devices worked so far. Actually Enttec MK2 and DMXKing ultraDMX Pro are apparently capable to handle 50Hz. Eurolite "PRO" devices are not.
• OpenDMX devices were running at 30Hz since ages (WTF) I already checked, and OpenDMX clones might flicker on Windows at 44Hz. That's because Windows sucks. Anyway, reducing the output frequency to 40Hz worked for me.
• The OpenDMX process was calculating the elapsed time between DMX frames with QTime, which is well known to be subject to system clock adjustments. No wonder why after many hours everything got frozen
• awkward and difficult frequency parameter tuning. I tried myself changing parameters on macOS, and it's a pain in the ass. Now output frequency can be set in the configuration dialog, in case some crappy clones are not capable of running at 44Hz. Default is 44Hz for every device.
  Screenshot:

  

What I've done is to decouple the engine core timer ticks from the actual serial line operations, which now happen on a dedicated thread. In case of input, another thread is started.
Also I used another Qt class called QElapsedTimer, with microseconds precision, to perform intra frame sleeps to guarantee the requested output frequency.

Note that this rework doesn't affect other plugins (like Peperoni or uDMX) but the same rework can be done there too.

[GGGss]

woow ... good catch (!) great think work Massimo

So now the use of processor less interfaces (read cheaper ones) will have the 'risk' of skipping DMX frames (since the core timer doesn't wait for the serial signal to be completed)
making (very) slow computers (RPi's) more responsive but the result on stage will potentially dramatic?

Does this logic goes inside the feedback mechanism also? (say you have your dmx interface set to 44Hz - will the feedback mechanism follow that tempo?)
albeit: What timer will be used if you have 2 or more DMX interfaces coupled with different timings? (You described it as 'a new thread will be created' but the internal timing will remain? correct?)

For forum members not acquainted with timing issues this small example:
If you close a switch (whatever kind) are you definitely sure that you will only get one flank change in the signal? NO ... not at all ... the lid may bounce up and down in split seconds before reaching its final position.

[mcallegari]

Feedbacks have nothing to do with the DMX USB plugin, so no, they're not affected,

[andres robles]

Hello everyone, my tests can not be considered decisive for lack of time during the tests
I have an "clone" of enttec pro rx / tx that never works at all correctly with any supposedly compatible software ... (chamsys, qlc +, freestyler ..)
with QLC + 11.12 test and after setting the pro rx / tx to 22hz (I guess it works at 44hz but capable of 22hz for rx and 22hz for tx) and apparently works for the first time correctly.
The DMX input of this device never worked well
it behaved with a kind of delay that was not always the same and with stopping reading the entry for seconds, so that a soft fade became stepped steps,
the output collapsed every 3-5 minutes, that is, a fx assigned to a movinghead worked fine, but every 3-5-10 minutes, even rarely 1 hour, it suffered a kind of restart, which is very annoying and it converted this device in useless.

Now in tests of no more than 20 minutes with qlc + and usb / dmx device manufactured by "work" with chip ftdi pro rx / tx everything works perfect, I guess it's a matter of finding the right frequency for each device

For the first time I can do that with this usb / dmx device and it seems to work correctly.

this device never worked well with any compatible software and with no compatible S.O (linux, mac, win ...)

now it seems to work, so I think that this rewrite in the code qlc improved the general compatibility with usb / dmx devices and got what no software, that I know (or know anyone who knows) that makes this device work properly.

I think this is a huge advance. Congratulations

tested linux version for 16.04