python3 externals for max (v0.1 - signed/notarized)
In case anyone's interested I have made a 0.1 release from my py-js project of two python3 (python 3.96) externals (py and pyjs) for Max, which are presently macOS x64_86 only and fully self-contained, relocatable, codesigned and notarized (making them appropriate for packages and standalones):
The py external provides a more featureful two-way interface between max and python in a way that feels natural to both languages.
The pyjs max external/jsextension provides a PyJs class and a minimal subset of the py external's features which work well with the max js object and javascript code (like returning json directly from evaluations of python expressions).
The release is distributed as a Max package which contains the externals and a number of patch examples. The project site itself also provides extensive documentation, additional build variations, and a branch which is working on Apple Silicon compatibility.
S
very cool!
Thanks @Rob
Nice to be able to finally share it (-:
Nice. How does it deal with interaction between UI and scheduler threads?
Hey @Nick, good question.
Right now as of v0.1, the python interpreter is not running in its own thread and just releases the python GIL (global-interpreter lock) as much as possible. This means that it can still lock up the UI if one doesn't use python's asyncio machinery or the python multiprocessing module. Of course this is not ideal but currently workable.
There is no particular reason why this current situation should continue however, I have just deferred to deal with anything related to threading and concurrency until later.
In the meanwhile, I have been considering a number of ways to solve this problem: directly running python in its own thread via the `systhread` machinery is probably the first way to go in the current implementation, and hopefully this will help python to play well in Max's multi-threaded architecture.
Another way that's a bit more left field, is to run python as a separate process and use zeromq as a bidirectional messaging transport in and out of max. I'm not sure how well this would perform, but in this method one could connect to the python interpreter from outside of max (a la the the Jupyter model) and potentially have some kind of repl to script Max.
Just want to add an additional clarification to my last post: the point of these externals is not to operate as real-time code, although their end-state should be that they do not disturb real-time code. Outside of these constraints, there's a lot that can be done usefully with a full embedded python interpreter, its stdlib, and the python eco-system.
I forget that I had an illustrative test in the project to show how the blocking is just to the ui thread and not to the scheduler thread (which handles clocking, and time critical operations in Max) and further not to the audio thread.
The test also shows that this ui-thread blocking can be readily overcome by making the python function call an asyncio or (asynchronous) call.
In any case, I've just updated this test to make this point even clearer:
I am very excited to integrate python in to Max. Thanks for sharing this!
My pleasure, @Anthony.
In case anyone's interested I have made a 0.1 release from my py-js project of two python3 (python 3.96) externals (py and pyjs)
Sweet! Can't wait to try it out @SHAKEEB :)