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 :(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Last edit: Massimo Callegari 2014-08-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Last edit: Cingulingu 2014-08-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
Last edit: Massimo Callegari 2014-08-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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 ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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 :(
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.
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.
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.
Last edit: Massimo Callegari 2014-08-27
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.
Last edit: Cingulingu 2014-08-27
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.
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
Last edit: Massimo Callegari 2014-08-28
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.
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 ?
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.