• State Not Answered
  • Date
    Jkar Gorostiza
  • Date
  • Replies 16 replies
  • Subscribers 87 subscribers
  • Views 22254 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
  • 0
    This feels like you want to use OSC through TCP and not UDP, but I don't know if Qlab supports that...
  • 0 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] 

  • 0 in reply to Jkar Gorostiza
    How do you decide, that qlab should listen to TCP and not UDP?
  • 0 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.

    .........????? 

  • 0 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. [:(]

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

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

  • 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