Getting input from ArtNet node.

sam_ · Wed Sep 23, 2015 2:14 pm

Hi,
has anybody any experience in getting a DMX input from a DMXking eDMX node?
The interfaces page here on QLC+ site says it works for both input and outpuit, so maybe it's something stupid I'm missing.
Anyway, I've tested it with both E1.31 and ArtNet protocols, in broadcast and unicast mode too.
QLC+ finds the node, is able to open the input plugin and receives packets, as far as I can see in the info tab, but I can get no response whenever I send something from my console, in either the virtual console or the input profile wizard.
Checking the input with the DMXking tool, I can see the interface correctly receives it.
Firewall has port 6454 open on UDP.
I'm on Fedora 64bit, QLC+ build 4.9.1.

Thanks,
S_

sam_ · Wed Sep 23, 2015 2:55 pm

Further testing with Artnetominator shows the interface is actually sending DMX over Artnet on the right universe.

OddSocks · Wed Sep 23, 2015 3:20 pm

Sam, in the input/output tab, once the universe is set up for input plugin, are you getting the little joystick symbol when you send data to QLC+?

sam_ · Wed Sep 23, 2015 3:56 pm

Thanks for the clue, OddSocks.
I had to patch the DMX IN to the fourth QLC+ universe, since the input is on the fourth universe of my interface.
The problem now is that I can only send OR receive DMX, but not both at the same time; is this really like this? There is no way of using one universe for input and one for output on the same board?

Thanks again.

mcallegari · Wed Sep 23, 2015 4:47 pm

Excuse me, but why on earth would you want to transmit and receive ArtNet on the same interface and on the same universe ?

Doesn't make much sense to me unless you explain in details your use case.

sam_ · Wed Sep 23, 2015 6:45 pm

Sorry for the misunderstanding, Massimo.

The board handles fours universes, I want to use one to get input from a simple DMX console to manage the virtual console and use the first three to output DMX.
The interface naturally has just one IP address, not one for each channel, so I must select the same node if I want to both send and receive DMX, but when I select the node for both input and output I don't receive input anymore. Obviously, the output universe set in QLC+ is different from the input.

mcallegari · Thu Sep 24, 2015 9:55 am

Thanks for the info. It's clear now.
I need to double check the code to see if there is a conflict between input and output universe.

However I would say you need to use 4 QLC+ universe (1-2-3 for output and 4 for input)

sam_ · Thu Sep 24, 2015 9:55 am

mcallegari wrote:However I would say you need to use 4 QLC+ universe (1-2-3 for output and 4 for input)

Sure, that's what the setup looks like now, but if I assign input to universe 4 it's working as long as no output is set on the same network on the other universes.

mcallegari · Thu Sep 24, 2015 9:55 am

sam_ wrote:Sure, that's what the setup looks like now, but if I assign input to universe 4 it's working as long as no output is set on the same network on the other universes.

Hi, I have a couple of changes to test.
There's surely something wrong with simultaneous input/output on the same interface.

Do you have the chance to build from sources ?

sam_ · Sat Sep 26, 2015 3:46 pm

mcallegari wrote:Do you have the chance to build from sources ?

I'm on Fedora, I can only build from sources.

mcallegari · Sat Sep 26, 2015 3:46 pm

sam_ wrote:I'm on Fedora, I can only build from sources.

Well, not quite. See the QLC+ download page

Anyway, change the following in plugins/artnet/src/artnetcontroller.cpp.
Please note that I'm referring to GIT sources.
If you use released sources, line numbers could be shifted a bit

line 320, replace

Code: Select all

if (this->type() == Input)

with

Code: Select all

if (type() & Input)

after line 324 (where there's qDebug...) add this:

Code: Select all

                                
if (!(m_universeMap[universe].type & Input))
	break;

mcallegari · Sat Sep 26, 2015 3:46 pm

sam_ wrote:I'm on Fedora, I can only build from sources.

Ping ?
This is pretty important, so please let me know if the changes work.

sam_ · Tue Dec 22, 2015 11:30 pm

Hi Massimo,
I'm really sorry for replying just now.
At first I would have said that it wasn't working; now I've been able to properly test it [Fedora 23 64bit, QLC+ built last week form sources ver 4.10.2] and it seems to be working after replacing the same lines of code.
The problem is it's working only in empty, fresh files. In any saved and re-opened session the only way to have it reacting to input is setting the input universe on 127.0.0.1 and not on the actual network on which the interface is.

Thanks,
S_

plugz · Wed Dec 23, 2015 8:25 am

Hello,

Can you test with this branch: https://github.com/plugz/qlcplus/tree/a ... aces-fix-2 ?

sam_ · Wed Dec 23, 2015 8:25 am

plugz wrote:Hello,

Can you test with this branch: https://github.com/plugz/qlcplus/tree/a ... aces-fix-2 ?

Hi plugz,
tonight I will compile it and give it a try.
Thanks.

sam_ · Mon Dec 28, 2015 12:00 am

So, after a bit of testing of plugz branch I have to say it seems to be working, no tricks needed also with saved files.
The only issue right now is that unlike 4.10.2, where response was pretty smooth, control it's a bit laggy and sometimes virtual faders get stuck halfway and reach the right input value just after a while.
I've noticed the activity LED on the interface keeps blinking now even when no data is sent in either direction, which was not the case in the stable release.
If you need me to run any more tests just ask!

Thanks,
S_

plugz · Mon Dec 28, 2015 12:48 pm

sam_ wrote:control it's a bit laggy and sometimes virtual faders get stuck halfway and reach the right input value just after a while.

This is strange, are you sure you didn't change anything other than using this different branch ? I'll do some tests myself.

sam_ wrote:I've noticed the activity LED on the interface keeps blinking now even when no data is sent in either direction, which was not the case in the stable release.

The ArtPoll packet is sent every 5 secs with this branch, this may be why the activity never stops.

sam_ wrote:If you need me to run any more tests just ask!

Thank you

plugz · Mon Dec 28, 2015 1:36 pm

plugz wrote:
sam_ wrote:control it's a bit laggy and sometimes virtual faders get stuck halfway and reach the right input value just after a while.
This is strange, are you sure you didn't change anything other than using this different branch ? I'll do some tests myself.

I just tested again and I have no latency issue.

plugz wrote:
sam_ wrote:I've noticed the activity LED on the interface keeps blinking now even when no data is sent in either direction, which was not the case in the stable release.
The ArtPoll packet is sent every 5 secs with this branch, this may be why the activity never stops.

Actually if you were already sending artnet through this interface, it should have been blinking too on the stable release.

sam_ · Mon Dec 28, 2015 1:36 pm

plugz wrote:
plugz wrote:This is strange, are you sure you didn't change anything other than using this different branch ? I'll do some tests myself.
I just tested again and I have no latency issue.

Uhm, tested again today and keeps doing it; not a big issue at all, I was just wondering why it didn't in the stable. But, yeh, since it's working now, maybe we can just close this thread.

plugz wrote:
plugz wrote:The ArtPoll packet is sent every 5 secs with this branch, this may be why the activity never stops.
Actually if you were already sending artnet through this interface, it should have been blinking too on the stable release.

Output was blacked out when running these tests, maybe it's worth testing with data moving in both directions?

plugz · Tue Dec 29, 2015 3:12 pm

sam_ wrote: Output was blacked out when running these tests, maybe it's worth testing with data moving in both directions?

Output was blacked out when running these tests with the master branch ? It would be nice to know if the latency issue is caused by my changes. If that is the case, then I messed something up.
Can you redo the tests with the master branch ? Thanks