• State Not Answered
  • Date
    Jkar Gorostiza
  • Date
  • Replies 16 replies
  • Subscribers 87 subscribers
  • Views 22260 views
  • Users 0 members are here

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 Reply Children
  • 0 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...
  • 0 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.

  • 0 in reply to Jkar Gorostiza
    Is your network just Eos and Qlab connected via an Ethernet cable?
  • 0 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.
  • 0 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.
  • 0 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)

     

  • 0 in reply to Richard

    Hi.

    First of all I want to thank you for all your help.
    Today I tried with a low performance swicht (10 / 100Mbps) and goes perfect. Richard, you were absolutely right. Thank you. The problem is solved. These were not erroneous configurations, but the direct connection between computers gave the failure. I followed your advice, and perfect. [:D]

    I want to thank you all for your help.

    Richard said:
    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.
     

Related

www.etcconnect.com