0

Questions about using rvNetwork.py

I am working on an external python application that uses the rvNetwork.py script to communicate with an open RV session. The workflow is that the RV session (running the ScreeningRoom browser) is launched, and then my application will be launched. It is conceivable that my application will be closed and re-opened numerous times while the RV session remains open, connecting/disconnecting as it goes. So far it is more or less working, but I have a few questions:

  1. I am registering some handler functions with RvCommunicator.bindToEvent(), and if you look at the implementation of bindToEvent() in rvNetwork.py, it is basically sending a Mu script string to RV that defines a Mu function and binds it to the specified event. The problem is that every time I run my application, after the first time, there is an error reported in the RV console about how these handler functions are being redeclared. Is there a way to prevent this? My application can't really know on its own that it has interacted with the RV session before.
  2. I am calling RvCommunicator.remoteEvalAndReturn() to obtain information from the open RV session and the results returned are Mu data structures encoded as strings. Is there a library somewhere that will convert these strings into equivalent python objects? Extracting bits and pieces using regexps and such feels like a very unreliable way to deconstruct the information buried in, for instance, a string containing a SourceMediaInfo structure.

Now I am not sure if issue 1 above has other implications, but I notice that the time it takes to get through the handler "binding" process gets longer and longer the more times I run my application (imagine a typical change-run-debug cycle) with the same open RV session. What is causing this increasing delay?

 

4 comments

  • 0
    Avatar
    Jon Morley

    Hi John,

    Regarding item 1 from above:

    You can get a tuple list of the existing bindings by calling commands.bindings. Please take a look at the documentation from the Help -> "Mu Command API Browser..." on the command.

    Alternatively you could use commands.unbind on the close of your application to make sure no dangling bindings exist. Again please have a look at that in API Browser.

    Regarding item 2:

    RvCommunicator.remoteEvalAndReturn() is a convenience wrapper for sending remote-eval and returning the Mu result. If you want to work in Python structures then I would suggest something more like the following with remote-pyeval:

        myInfo = eval(rvc.sendEventAndReturn('remote-pyeval', 'rv.commands.sourceMediaInfoList("sourceGroup000000_source")'))

    Now myInfo is a list of dict objects you can use in normal Python ways like:

        print(myInfo[0]['viewInfos'][0]['name'])      # output: u'track 1'

    General comments:

    It is highly recommended that you do your heavy RV lifting from a package inside RV and then make simple calls over rvNetwork from outside. With such a design you can more rapidly prototype your RV mechanics while keeping the demands on the network communication complexity very low. Does that make sense to you? Have you considered such a design?

    Please let me know if there is anything else I can help clear up.

    Thanks,
    Jon

  • 0
    Avatar
    John Cooper

    Thank you very much, Jon. You provided me with exactly what I was looking for.

    You are right that I would probably do well to migrate this over to a package inside RV, and that may very well happen at some point. But I don't really have a good grasp of how to build packages or deploy them to RV, and even then it is a non-trivial matter with the way applications in general are deployed, wrapped, and launched here. For instance, none of the rv python modules are installed to any of the python directories at this facility, so I can't even write python scripts with "import rv.commands" in them. This is further complicated by the fact that these tools need to run from within numerous embedded python environments (Maya, Houdini, Nuke, etc.) which are themselves just "engines" running within a Tank context.

  • 0
    Avatar
    Jon Morley

    Great John!

    If the day comes where you want some pointers into moving your logic into an RV package please let us know. I should also mention that there is no way to import from the rv Python module outside of RV. That mechanism is bound to our own Python interpreter. Without running your Python from our py-interp process there is no way to access those calls. That is why rvNetwork and rvSession are meant as a bit of a bridge to that functionality, but for more serious manipulation of RV's state it is better to write packages.

    Thanks,
    Jon

  • 0
    Avatar
    John Cooper

    Ah, okay, that makes sense. Thanks!

Please sign in to leave a comment.