This feature request is for a node that is able to accept Python code.
Instead of accepting different input types, (such as lists etc) it may be really useful to simply allow this node to parse Json, as a way of controlling composition flow, etc.
Considering that Python would not be fast enough, (pure Python) for image / audio processing, using Python as a control language for Vuo could make more sense.
There are already many tools within Python to work with Json already, so this could be very useful as IIRC that Vuo already uses Json as the format to connect nodes together?
Also there are many external libraries (such as NumPy) that do allow fast processing of data, so possibly we could access different types of Vuo data simply from the Json string?
This sounds good to me, yet another language to learn, but I learnt enough JS to process point data and transform it in JS for QC and Python is way easier to use than C for beginners and advanced coders.
@useful_design I know it’s yet another language, however python makes trivial many logic based operations in C. So for logic and composition control python is very flexible, just not fast enough for processing large data quickly.
Added to this that python is an extremely popular language- and used in many 3D softwares already.
@alexmitchellmus yep. Certainly Python is popular in 3D/science and has lots of function libraries etc.
In the early days of pre-alpha Vuo I was naively musing about how it could be a multi-language platform where people could pull code from different places in a bunch of languages like Python, R, JS, whatever and shuffle data between them and then put it into the visual nodes of Vuo for display. Especially if it became easy to build a data dashboard and/or GUI in Vuo like say it is in, Origami (think Qt without the code). Compile to app makes it quite desirable, especially if more platforms opened up as compile candidates.
I’m wondering if Javascript might be more suited, it tends to execute much faster, although I guess speed wont be the thing for number crunching, there’s always C for that, and it’s the most well known CS language around.
QC is known to have issues around the JS patch, Bonix found half their BonixTV crash reports were associated with the JS patch so they wrote their own Lua patch (which is also faster). Converting Javascript patches to Lua reduced the number of crash reports dramatically for BonixTV/mimoTV IIRC.
I think with Node.js becoming so popular so other implementation of JS for a Vuo node other than the questionable Apple engine would be possible.