qlab controlling eos nomad cue timing issue

I got qlab calling cues in nomad thanks to this forum. However,  when I call a cue out of order it snaps to the cue.  I have used midi with our old 250 board and I am used to calling cues out of order because it always uses the timing of the called cue. Without this I'll have to rethink this whole setup.   Can this be fixed?   FYI:  Using osc string. eos/cue/xx/fire  in qlab.  Maybe I should try direct midi instead?  Or a different string?  

Thanks.

  • I think the command you are sending is more or less the same as typing cue n which is different to GoTo Cue n which is what you need to do for cue timing.

    I dont have things setup to test this out but the documentation at github.com/.../Eos OSC Keys.pdf indicates that you can directly send the key strokes via osc.

    So probably doing /eos/key/go_to_cue as the basis for what you are wanting to would be what you could try.

    Documentation is somewhat lacking on the eos osc strings, so can't tell if you would then send additional /eos/key/ commands or you can string them into the same osc string.

    ie either

    /eos/key/go_to_cue
    /eos/key/4
    /eos/key/enter

    or maybe but less likely

    /eos/key/go_to_cue/4/enter
  • An update to my previous reply, it is a bit simpler than I said.

    You can simply send the command line via osc.

    So you should be able to send

    /eos/cmd/Go_To_Cue/100/enter

    The "Eos Integration via OSC.pdf" manual says

    "Your may also modify Eos show data. Typically you should build Eos command lines and send them with the command /eos/cmd or /eos/newcmd. "

  • /eos/cue/xx/fire should fire that cue with it's recorded timings (I use this all the time) - if it's snapping it suggests something odd is going on. Using /eos/key/go_to_cue wouldn't be brilliant as this would just take you into the cue in the default time

    I'm assuming that running the cues by pressing Go on the desk is working as expected?
  • In reply to richardWilliamson:

    Yes you are correct. The problem was that I was using blank test cues. Ion overthinks and when going between identical cues out of order it snaps (0 time) . Once I added unique channel values to each cue, eos/cue/xx/yy/fire worked perfectly even out of order.
  • In reply to Mike A:

    Thank you for the github link. I saw it somewhere else but hadn't saved it. I figured out my problem was about my test cues not the coding of my osc.
Page 1 of 1
Related