DMX USB plugin rework

Cingulingu

I'm glad to help. You can see the entire VM on the link above. Just click on download log to see the entire procedure. gcc,qt,libftdi,.. I think is gcc-4.8-2.1.2 for 13.1 for the others is the same procedure.
Massimo Callegari

Hi Santiago, the crash is confirmed. I will fix is ASAP.
Thanks
Cingulingu

Hi Massimo. I have tested the last code from git (uchar-char, request.prepend(m_out2reqCode);), the error still persist.
Tested with "ENTTEC_PRO_SEND_DMX_RQx", working.
Massimo Callegari

Ok, this is definitely getting more and more weird.
In theory those DMX_RQx are loaded into char variables wich shouldn't mess things up.
I am really wondering why the compiler works in my case and not in yours.
I'll attempt another way...hopefully the final one :(
Cingulingu

NO GO. I think that your code is OK. It seem that the MK2 is not correctly detected and therefor the I/O are wrongly treated as a kingmax.
I will revert the if statement and test it. I will report you back.
Cingulingu

YES! That is what happen. I interchanged the the lines 39,40 with 82,38 in enttecdmxusbpro.cpp "BEFORE THE LAST CHANGE" (last yesterday) and now the mk2 works correctly. It seams that the detection is not passed to the plugin.
Massimo Callegari

Still weird. Can you test the today's code and see if it works ?
In case it doesn't, can you add a debug message in the EnttecDMXUSBPro::setDMXKingMode() function and see if it gets called in the Pro Mk2 case ?
If you see it then it's not correct.
Santiago Benejam Torres

Tested 4.7.5 from GIT with qt4 on Ubuntu 14.04 64bit. Works well. The only problem I found is that the script create-deb.sh fails on some tests.

Good job Massimo.
Cingulingu

The today code doesn't work either. I think I get close to the problem. Still don't know why, but the " m_dmxKingMode " is set to TRUE.
when selecting the type of request.prepend, even when the DMXUSBWidget::Type return MK2.
The rest of the code is working. The old and the new have the same issue.

I added a debug in EnttecDMXUSBPro::setDMXKingMode(). And yes is called.

Question,
where can I found the decision string whether the device is a kingmax or an pro/mk2 which set m_dmxKingMode to true/false. EnttecDMXUSBPro::setDMXKingMode() in term set the m_dmxKingMode to true.
Cingulingu

I have changed a little the EnttecDMXUSBPro::setDMXKingMode() to this:
void EnttecDMXUSBPro::setDMXKingMode()
{
if (name().toUpper().contains("PRO MK2") == true)
m_dmxKingMode = false;
else
m_dmxKingMode = true;
qDebug() << "setDMXKingMode of:" << name() << m_dmxKingMode;
}

And now is working.
Massimo Callegari

This doesn't really make sense to me.
Have you ever forced the type of your device ? (double check in the DMX USB configuration panel)

The DMX USB detection has two phases:
1- create the widgets with forced types
2- create the widgets depending on their names/vendor/ESTA ID

Forced types are saved in the QLC+ configuration file ($HOME/.config/qlcplus/Q Light Controller Plus.conf)
Please remove it and try my sources without your patch.
You recognize an MK2 cause it has also the MIDI IN/OUT lines.

If you don't see them, then there is something wrong in the detection.

Please let me know
Cingulingu

Yes, it's working. You were right. I forgot to clean qlc.conf after the last change.

P.S. Is there any possibility to add a configuration tab for pro/mk2 to change the DMX-frequency.

Thank again.
Massimo Callegari

Right now the DMX frequency is a parameter dedicated only to the ENTTEC Open devices.
The explanation is simple: since they are unbuffered, they are the only devices with a dedicated output thread. (so you can tune the output frequency)
All the other devices are supposed to be buffered (the Mk2 is one of them) so there shouldn't be the need to have an extra buffer inside QLC+.

May I ask why do you need such control ?
Cingulingu

I know about the buffered/unbuffered types. I usually work in live situations, with vary different setups every time. And it will be vary useful if the freq, of the pro, can be changed for slower and faster setups. I thing it is just a mater of sending some commands to the device. And not to use the pro-manager, specialty because it is for win only, and I relay don't won't to use a win machine for obvious reasons.
Massimo Callegari

Santiago, debian package creation should be OK now.
Post Reply