- Where is the documentation for the RV command API?
Right now we don't have a Python specific way to read the docs. However, the Mu API doc browser does have the information. Help->Mu Command API Browser will launch the doc viewer. The leftmost column has items marked with a blue icon: these are Mu modules (these roughly correspond to python modules). The "commands" and "extra_commands" modules in Mu are documented and make up the RV API to both Mu and Python. So by reading those docs you can figure it out (plus they have the real types that will be returned)
Something to note about the doc browser: there's a search bar at the top of the window.
- What version of Python are you using?
- Can you make it version agnostic? Why Python 2.6?
For better or worse, we plan on tracking what the foundry is using. Its already too complicated out there.
- When I try to call a function in rv.commands its failing. Why?
We do not yet handle default arguments so you have to supply all of the command arguments. UPDATE: rv 4 now handles default arguments in python.
- How do I make UI in Python?
You can use either PySide or PyQt to make Qt interface components (RV is a Qt Application). We don't distribute compiled versions of either one of these Qt wrappers in Python, but both should work. PyQt is by far the more common wrapper of the Qt API. Note that when you compile PyQt or PySide, you'll have the best chance of the result working in RV if you link with a version of Qt close to the one used in RV (currently Qt 4.8.0).
For completeness you should know that the makers of PyQt require a license to use their code (even in RV). We don't have that license and even if we did its not transferable to the end user (it would only cover our use of it). However you can purchase a license from them if you want to be in full compliance with their licensing. PySide has no such license requirements.
- Can I draw on the view the way Mu does using OpenGL?
Yes. If you bind to a render event you can draw using PyOpenGL if you have it installed.
- Didn't you guys say Python would cause performance problems with OpenGL drawing?
Yes. But we were probably wrong. The issue was whether or not Python's cyclic garbage collector would run in the middle of a render. Turns out it only runs when you're almost out of memory.
- Can I call existing Mu code from Python?
Yes. The reference manual has a section on this. You can wrap any Mu function using a MuSymbol in Python and then call it. This is how the command API is constructed in Python.
- How was Python compiled for RV (and Unicode Support)?
On OS X we don't actually compile Python, but instead are using the OS provided Python 2.6 installation and .dylib. That version uses UCS2 for unicode. Modules that load in the system python 2.6 should work in RV.
On Windows we compile UCS2 using VC9 for 3.12.14 or older, VC10 for 3.12.15 or newer.
Linux is UCS4 since most of the distros use that. We use GCC 4.2 to compile on Linux.
- Module XXX is missing. Where can I get it?
If the module is a "standard" Python module (it comes with the Python distribution for the platform you are on) than its hopefully included. For openSSL dependent modules, we may build it but not include openSSL. On OS X we use the system Python 2.6 so if your module runs in the system python interpreter it should run in RV. On Linux we've tried to make sure everything is included. On Windows we compile the same way that the Python binary distribution is compiled.
If the module is not included and its a CPython module (written in C) you will need to compile it yourself.
- The commands.bind() function in Python doesn't work the same way as in Mu? How do I use it?
The Python version currently requires all arguments to bind(). So to make it the "short form" do:
bind("default", "global", event, func, event_doc_string).
- Can I do leader and overlay scripts in Python for RVIO?
Not yet. We'd like to make this work, but it's a chunk of work that's not scheduled at the moment.
- Doesn't the Python <-> Mu bridge slow things down?
Maybe not a frequently asked question, but the answer is: not really. The MuSymbol type used to interface between them can completely skip interpreted Mu code if its calling a "native" Mu function from Python. All of the RV commands are native Mu functions. So there's a very thin layer between the Python call and the actual underlying RV command (which is largely language agnostic).
The Mu calling into Python bridge is a bit trickier: its basically the CPython API exposed. So its roughly the cost of calling a Python function from C.
- Why does my external Python process (which I call from RV) now behave differently?
This is probably caused by the fact that RV modifies the PYTHONPATH to incorporate $RV_HOME/plugins/Python and $RV_HOME/lib/python2.6 in order to run. Forked processes will inherit the PYTHONPATH. If you are using QProcess to launch the external process you can call QProcess.setEnvironment() to set the PYTHONPATH prior to calling QProcess.start().
Python FAQ (customization and extension)
Article Last Updated: