Eos-Nomad with Qlab Instability

hello everyone.

I can not run Qlab (v 3 .... v 4) in stable mode with EOS-NOMAD via OSC. By midi (MSC) the interaction is totally reliable and does not present any problem ... but OSC has a greater potential of instructions, there my obsession to make it walk.

My goal is for EOS-NOMAD to activate the QLAB cues, and it does so but in an irregular way which gives a lot of insecurity. In the soft EOS does not seem to be the problem, if we go to Tab 99 (diagnostics) and put (On) Outgoing OSC we see how EOS sends the instruction string (send String: / cue / 1 / start) (OSC Packet), in Qlab click Status, open the Logs tab and activate OSC input to see what goes in ... and here we see that sometimes the instruction string arrives and others do not, it is lost.

These are the configurations. What am I doing wrong? Where is the error?

Thank you.

Parents

0 ueliriegg over 7 years ago

This feels like you want to use OSC through TCP and not UDP, but I don't know if Qlab supports that...
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Jkar Gorostiza over 7 years ago in reply to ueliriegg

Hi ueliriegg.

Thanks for showing interest. In the qlab tutorial says:

QLab accepts incoming OSC messages via TCP and UDP over a local network.

All software or devices which support OSC have their own dictionary of commands. You can use hardware like ETC's EOS family to send messages that exist in QLab 4's OSC dictionary.

Any other suggestions?

Thank you.

Launch from EOS cue 1 to activate in Qlab (/ cue / 1 / start).

Qlab does not receive the order, the music track does not activate.

Second try. I throw again from EOS the cue 1 containing for Qlab (/ cue / 1 / start).

Now if the audio track sounds. In the status window for OSC in Qlab, the EOS command is seen to have entered.

I shoot the cue 2 of EOS to tell Qlab (/ cue / 1 / stop), for the audio ..

... but qlab continues to play the audio .... the stop order is lost ...

Puff ... I do not know ... what to try... [C] [*-)] [C]
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 ueliriegg over 7 years ago in reply to Jkar Gorostiza

How do you decide, that qlab should listen to TCP and not UDP?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Jkar Gorostiza over 7 years ago in reply to ueliriegg

I wanted to check in reverse ... activate with Qlab (v 4.0.4) the cues of Eos through OSC, but I have to say that I find it impossible for now, however with Qlab (v 3.1.24) without problems .

In the version of Qlab 4.0.4 to activate the signals from Eos you have the options to send by OSC or communicate by UDP, but I can not do either.

My conclusion is that Qlab in its new version presents difficulties to work with OSC .... problems that will correct.

Corrections in the new version.

QLab 4.0.5 Release Notes

FIXED: QLab is now less strict about requiring the expected number of arguments for certain OSC commands, allowing third-party software that always sends OSC arguments (e.g. TouchOSC) to again work with certain QLab OSC methods.

.........?????
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Jkar Gorostiza over 7 years ago in reply to Jkar Gorostiza

I wanted to check ... activate with Qlab (v 4.0.4) the cues of Eos through OSC and.... [:P]

The situation is the same .... [:@]

... it works at times, in an irregular way, does not offer any stability. [+o(]

I will continue to use midi (MSC) at least guarantees of good performance. [:(]
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Sammy over 7 years ago in reply to ueliriegg

QLab does support a TCP connection but only as a Server and also only OSC 1.1. The problem here is that both QLab and Eos only support TCP as servers. You would need to use OSCRouter to be the in between to create two TCP connections and pass the messages between. If you have your heart set on a TCP connection....
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Sammy over 7 years ago in reply to Jkar Gorostiza

Your last photo show's that Eos sent a cue firing OSC command but no specific OSC String, meaning the problem is either the connection between Eos and Qlab and a packet being lost, or on the Eos directly...
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Jkar Gorostiza over 7 years ago in reply to Sammy

Hi.

First of all, thank you for your good guidance and dedicated time.

After reading a little in the ETC forum and Figure53 .... I see that the interaction between Eos and Qlab using OSC does not seem to be a new problem. The intermittence in its correct functioning.

I want ETC and Figure53 to improve collaboration synergies to make both systems more user friendly (OSC), without the need to resort to complex configurations. [+o(]
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Jkar Gorostiza over 7 years ago in reply to Sammy

Hi.

You're right. Qlab does not accept OSC for TCP. Only by UDP. So we already know about OSC-TCP using Qlab is not the best option for a live show.

https://groups.google.com/forum/#!topic/qlab/4bOciZDDs4o [:-*]

https://groups.google.com/forum/#!msg/qlab/iMvjwgonBqk/OPZjXipLCAAJ [:-*]

Regards.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Sammy over 7 years ago in reply to Jkar Gorostiza

Sorry Jkar, I think you are misunderstood. QLab does accept OSC via both UDP and TCP.
It's set up is very similar to ETC's implementation on their EOS Consoles.

A TCP Connection can be established and used but... neither software allows a TCP connection to be established from their end. What this means is both QLab and Eos allow a TCP "Client" to connect to them and act as what we call a "Server". When a Client has connected to them they will quite happily return messages via TCP, but that initial connection must be instigated from a Client. As both pieces of software can't act as a client then you can't set up a TCP connection between the two without a third party application e.g OSCRouter.

Our problem is that both software can't send TCP OSC messages on a cue executing level... Well, debatably Eos can to an extent, but it can't send an OSC messages via TCP if you were to execute an OSC String from a Cue... Anyway I'm digressing.

As Chris Ashworth (Figure 53) explains sending OSC messages via TCP is not just as easy as ticking a box, with the ability to create a long lived connection you offer up questions such as what happens if the connection disconnects during a show? How do you monitor the connection? Do you continually Ping them? Do you then have to create a whole new user interface and feedback/monitoring system just to see the OSC connections that should be/currently active...

That all said the problem isn't at all TCP or the lack of it. It looks very much like a packet has been lost between the Eos and QLab from your photos. I'd look more into your network...
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Jkar Gorostiza over 7 years ago in reply to Sammy

Oops...! [+o(]

I am grateful for the clarification on such a complex subject. Is the best way to improve. I have to clarify that my point of view is only as a user. I use google translate, I think that explains the difficulties of understanding ..

You suggest that the problem may be in my network ... what type? The network settings are seen in the first photos of the publication.

I understand that with OscRouter the problem is solved?...And how is OscRouter configured so that Eos and Qlab are understood? I would like to send from Eos to Qlab.

Thanks for your patience.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Sammy over 7 years ago in reply to Jkar Gorostiza

Is your network just Eos and Qlab connected via an Ethernet cable?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Jkar Gorostiza over 7 years ago in reply to Sammy

yes. UTP CAT-5 crossover and no crossover. Directly from computer to computer, without router. I have to add that to rule out a possible failure of network cards, I have tried it on different computers and the problem is the same.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Richard over 7 years ago in reply to Jkar Gorostiza

It is always best to have a switch in the middle.

Many network cards want to see the other end running before they can properly link up. If they don't start up in the right order, you may end up with no link, an intermittent connection, or a very slow (half-duplex 10 Mbps) connection.

In some cases, both ends want the other to be turned on first - which is of course, impossible to do.

If you have a switch in the middle, it can be turned on before either machine (or application) is started, avoiding this problem.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Jkar Gorostiza over 7 years ago in reply to Richard

Hi.

Thanks everyone for your help.

Thanks Richard for the interest..... swicht o router?

change of plans. I follow the guide ...https://figure53.hostedwiki.co/pages/QLab%203%20Tips%20and%20Tricks

Same instability. Does anyone see the error or failure?

Another forum where the problem is exposed ...

https://groups.google.com/forum/#!topic/qlab/Y-Ob3Fx13rc

Buuff... [C] [C]

UDP Strings & OSC" are enabled in the Eos shell settings

OSC TCP format for OSC 1.1 (SLIP)
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Reply

0 Jkar Gorostiza over 7 years ago in reply to Richard

Hi.

Thanks everyone for your help.

Thanks Richard for the interest..... swicht o router?

change of plans. I follow the guide ...https://figure53.hostedwiki.co/pages/QLab%203%20Tips%20and%20Tricks

Same instability. Does anyone see the error or failure?

Another forum where the problem is exposed ...

https://groups.google.com/forum/#!topic/qlab/Y-Ob3Fx13rc

Buuff... [C] [C]

UDP Strings & OSC" are enabled in the Eos shell settings

OSC TCP format for OSC 1.1 (SLIP)
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Children

No Data