OSC patch synchronisation doesn't work

I may be wrong but it appears that the OSC API for patch doesn't work as described - I can pull the patch details on the original sync, however when changed are made to the patch the notification I recieved seems to be of the form /eos/out/notify/patch/list/0/1 with a single integer argument which increases for each update - I haven't found a way of using this argument to then pull the actual change

My understanding is that the channel or part number (and ideally address?) should be sent on a patch update, allowing the data for that object to be pulled - failing that sending /get on the index sent should return data on all the affected objects..

Am I missing something?

 

Thanks

Parents
  • Thanks Richard. I've written this up as - RND 0043982: OSC - Patch notifications do not contain a list of changed targets.
  • Is this still not resolved? I am just playing with OSC subscriptions and I am able to see on a cuelist change that I receive two integers. The first seems to be a count of notifications, the second what I expect as the cue modified. 

    For the patch, I seem to only get the incrementing notification count back.

    I'm no expert, so it certainly could be just me not understanding.

  • To test, I recorded three cues in List 1, being Cue 1, Cue 2, Cue 3.5. 

    When I've recorded Cue 3.5 for the first time:

    [ 13:26:31 ] [13:26:31] TCPIN [10.101.92.101:3037] [OSC Packet] /eos/out/user/1/cmd, LIVE: Cue 3.5 : Record Cue 3.5 #(s), 0(i)
    [ 13:26:31 ] [13:26:31] TCPIN [10.101.92.101:3037] [OSC Packet] /eos/out/cmd, LIVE: Cue 3.5 : Record Cue 3.5 #(s), 0(i)
    [ 13:26:31 ] [13:26:31] TCPIN [10.101.92.101:3037] [OSC Packet] /eos/out/previous/cue/1/2
    [ 13:26:31 ] [13:26:31] TCPIN [10.101.92.101:3037] [OSC Packet] /eos/out/previous/cue/text, 2 5.0(s)
    [ 13:26:31 ] [13:26:31] TCPIN [10.101.92.101:3037] [OSC Packet] /eos/out/active/cue/1/3.5, 1.000(f)
    [ 13:26:31 ] [13:26:31] TCPIN [10.101.92.101:3037] [OSC Packet] /eos/out/active/cue/text, 3.5 5.0 100%(s)
    [ 13:26:32 ] [13:26:32] TCPIN [10.101.92.101:3037] [OSC Packet] /eos/out/notify/cue/1/list/0/2, 6(i), 3.5(s)
    [ 13:26:32 ] [13:26:32] TCPIN [10.101.92.101:3037] [OSC Packet] /eos/out/notify/cuelist/list/0/2, 7(i), 1(i)

    And an update:

    [ 13:31:50 ] [13:31:50] TCPIN [10.101.92.101:3037] [OSC Packet] /eos/out/user/1/cmd, LIVE: Cue 3.5 : Update #(s), 0(i)
    [ 13:31:50 ] [13:31:50] TCPIN [10.101.92.101:3037] [OSC Packet] /eos/out/cmd, LIVE: Cue 3.5 : Update #(s), 0(i)
    [ 13:31:50 ] [13:31:50] TCPIN [10.101.92.101:3037] [OSC Packet] /eos/out/notify/cue/1/list/0/2, 8(i), 3.5(s)
    [ 13:31:50 ] [13:31:50] TCPIN [10.101.92.101:3037] [OSC Packet] /eos/out/notify/cuelist/list/0/2, 9(i), 1(i)

    So the thing that has been recorded, then changed, is List "0", item "2" (both of these are "engineer-counting" where 0 is the first thing).  the 3.5(s) is the (s)tring of the item that was changed, being Cue 3.5.  the 8(i) or 9(i) is the integer Index number of the change.

    If you make a change in Patch, we do not provide a string of the thing that was changed (like "Chan 1" or "Chan 7 Part 12") which would be nice.

  • If you make a change in Patch, we do not provide a string of the thing that was changed (like "Chan 1" or "Chan 7 Part 12") which would be nice.

    Yes. This seems to be the concern of the original post, as well as mine.

    We can agree that the cuelist notification is working as expected. I only commented about cuelist to indicate that I indeed was seeing the expected return of an indicator of the item that was changed unlike the patch notification.

    The patch notification does not seem very useful without telling you what was modified when you likely will have hundreds or thousands of possible channels or parts. Without this you would need to pull the entire patch again to keep in sync. 

    I was inquiring about the status as it appeared that this "problem" was understood and that a case had been created to address this 5 years ago:

    Thanks Richard. I've written this up as - RND 0043982: OSC - Patch notifications do not contain a list of changed targets.

    Page 599 of the current 3.1.0 Operations manual seems to indicate that this information is expected to be returned the same as in the cuelist example:

    Integrating Your App with Eos: Step 3 – Staying in Sync

    Your app can now request all of the show data from Eos, but if a user is editing show data, your app would become out of sync.  The solution to this is to subscribe to Eos show data changes with the following command: /eos/subscribe = (where 0=unsubscribe, 1=subscribe) While subscribed, Eos will send the following commands when Eos show data changes: In the reply, the first argument will be a sequence number, followed by a list of the targets that changed.  The targets are specified OSC Numbers and / or OSC Number Ranges

    • /eos/out/notify/patch/list/<list index>/<list count> = <uint32: sequence number>, ...
    • /eos/out/notify/cuelist/list/<list index>/<list count> = <uint32: sequence number>, ...

    Sorry to bring up such an old thread, but i did not find any other threads and the fact that a case was opened seemed like a good starting point. Hopefully this can help improve the use of the product. 

    Thanks for your help looking in to it  . 

  • My apologies, I misread your question.

    I agree this is still a bug in current code.  I do not have any indication of when it may be corrected, but I have added a comment to the SCR that it is an ongoing issue for users such as yourself.  

Reply Children
No Data
Related