I also don’t know about hybridizing, but… a straightforward way to integrate SC with OpenCV in Python would be to run SC and Python in separate processes, and pass the data that you need between the processes using Open Sound Control.
Trying to run two language interpreters, with radically different designs and core assumptions, in the same process is likely to be difficult and full of bugs. Considering that there’s already an easy way to pass information between processes, the benefit of hybridizing is probably much much less than the effort it would take. (Consider also: If you have an OpenCV/Python thing that sends OSC, you can use it with SC, Pd, Max, Touch Designer, vvvv, Processing, etc etc, at no additional cost, but if you try to run Python inside an sclang process, you’ll rip your hair out and then end up with something that you can’t use with other software. A decoupled solution is usually better than a tightly coupled one… not always, but usually.)
I was enjoying the code Smoge posted, I know it was a library imported and some conditional loops with a for and while, but not shure if the library was OpenCV, I have to admit I donnot manage OpenCV, anyway dear James you have reason, to hibridize codes into langauges must be a way to create lots of bugs, for now my knowledge in Python is to use GUI libraries and Functions. as you can see here:
PS: Sorry for some sofeggio exercises that are in the channel /University assignments/ not Python.
I shouldn’t say it’s impossible – for example, Max/MSP has a [js] object to embed JavaScript, and [jit.gl.lua] for Lua. Pure Data has [pdlua].
In those cases, the languages are designed to be embedded. Apparently Python can embed as well, though it looks like it isn’t super-easy. In SC, it would be necessary to add primitives, which would always have to be installed for everyone (but not all users will be interested). I’m not certain whether or not this could link dynamically to a Python interpreter, or if we would then have to ship Python as well… it’s some work.
At that point, you have to consider what you get for the effort.
Scripting languages embedded into graphical patchers are valuable because patching has serious deficiencies when it comes to conventional algorithms… some things that are so painful to do with Max or Pd objects that nobody will ever try to do them. (Some of those would be a breeze in JS or Lua.)
By contrast, even though many users complain of some out of date elements in SuperCollider, it’s still true that sclang boasts a relatively complete feature set. I was able to write a parser and compiler for a live coding dialect completely in SC. So the benefit of embedding Lua/JS/Python in SC would be much, much smaller than the benefit Max and Pd get from their scripting objects.
But again… for the specific use case you mention… you will get considerable gains in terms of stability, simplicity of code, and flexibility by running OpenCV in a separate process, and sending data using OSC. Have a look at OSCFunc in sclang, to receive OSC. It’s pretty straightforward.
For this application, IMO it is not worth it to try to embed Python-running-OpenCV into the same sclang process. There’s an easy way (OSC) and a hard way (embedding)… just use the easy way.