python bindings for openframeworks

I’ve been messing around with python extensions lately and thought it would be a neat idea to create python bindings to openframeworks for some rapid development. You can test ideas out quickly, instead of having to compile over and over. Since the functions are bindings performance is good, good enough to code your final projects in python! Of course C++ is faster but so far I havn’t noticed a slowdown in performance. On the examples the frames per second of the C++ version is almost exactly the same as the Python version. Here is some example code and output:




There are some things that need to be fixed… audioRequested/audioReceived acts very wierdly… causing python to crash. I believe this is because ofSoundStream is non-blocking but maybe I’ve made a mistake in the extension… the only solution I see for now would be changing it to blocking, just like the other audio/video libraries. Pretty much everything else works.

Who’s interested? I’ll release it if enough people want it. First I gotta fix some bugs but overall its pretty functional.

The only prerequisite is of course python. The package binds openframeworks and thus all the libraries it uses.

Example program (third screenshot)

  
  
from openframeworks import *  
import math  
  
class testApp(ofSimpleApp):  
    def setup(self):  
        ofBackground(0,0,0)  
        self.counter = 0.0  
        self.spin = 0.0  
        self.spinPct = 0.0  
          
    def update(self):  
        self.counter = self.counter + 0.029;  
        self.spinPct = self.spinPct * 0.99  
        self.spin += self.spinPct  
          
    def draw(self):  
        x = 0; y = 0; R = 90.0; r = 50.0; O = 80.0  
        ofSetColor(255,255,255)  
        for i in range(1,800,1):  
            xPct = i*self.mouseX*0.0001  
            yPct = i*self.mouseY*0.0001  
            xPct += self.spin * 0.002  
            yPct += self.spin * 0.003  
            if self.mouseX:  
                r = self.mouseX/10.0  
                O = self.mouseY/10.0  
            x = (R+r)*math.cos(xPct) \  
                - (r+O)*math.cos(((R+r)/r)*xPct)  
            y = (R+r)*math.sin(xPct) \  
                - (r+O)*math.sin(((R+r)/r)*xPct)  
            ofRect(600 + int(x), 320 + int(y), 2, 2);  
        for i in range(0,20):  
            ofSetColor(255-i*10, 255-i*20,0)  
            ofLine(0,i*4, ofGetWidth(), i*4);  
              
    def mouseMoved(self,x,y):  
        self.spinPct += y*0.01  
        self.spinPct += x*0.01  
              
ofSetupOpenGL(800,700, OF_WINDOW)  
ofRunApp(testApp())  
  

As you can see everything is pretty much identical except for the python flavor.

looks great!
i’d very much like to see a release!

best
joerg

wow,that’s so great,i m python lover!

wow - that’s great :slight_smile:

theo and I are supremely happy to see this - we’ve been wondering for a while if this would be possible, and it’s great to see that it is. I’ve created a separate forum about this topic, since I know that there has been alot of interest in this.

please let us know how we can help ! we’d love to see this part of the official release, and we’ve received already a bunch of emails from folks asking us about the possibility of working in python, either through bindings or through using the c++ python interpreter.

audioRequested/audioReceived acts very wierdly… causing python to crash. I believe this is because ofSoundStream is non-blocking but maybe I’ve made a mistake in the extension…

audioRequested works via callback but it is a callback from a different thread then what is running OF… it might be that you need a way to kick off that thread yourself from python - I’m not sure. It would be hard to run it like the video player / video grabber (with an isFrameNew() type approach) because the callbacks happen more often then the framerate itself… I can provide you with some simpler threaded callback code if you want to work with something basic to begin with.

thanks!!
zach

wow - that’s great :slight_smile:

[quote]
audioRequested works via callback but it is a callback from a different thread then what is running OF… it might be that you need a way to kick off that thread yourself from python - I’m not sure. It would be hard to run it like the video player / video grabber (with an isFrameNew() type approach) because the callbacks happen more often then the framerate itself… I can provide you with some simpler threaded callback code if you want to work with something basic to begin with.

Yea it was indeed a threading issue. I’ve fixed it! All thats left is to do some opengl type conversions. everything in openframeworks is pretty much covered.

Ok. Well version 0.1 of the bindings is ready to be released but I have a question. I’m wondering if its okay to redistribute openframesworks python bindings as a seperate project. Seperate because I’m going to modify the codebase in the future. I wanna add vector suport (cairographics.org) / svg support, include extra classes (not as addons, but as part of the main source); Easing algorithms, audio effects(reverb,etc), image filters (blur, etc). Classes for shapes (reuse vectors), movieClips… That plus a few other ideas I have. You guys will be credited for all your work. Of course you can distribute it with openframeworks if you like and don’t mind it being a bit different… You can add any of the modified code to the original project if you want. I’m adding these changes since I wanna use them in a new project. Is that ok? There can be two versions of the bindings (one a direct copy, the other one a more modified version), but I don’t wanna do that, since its doesn’t make sense to have two python libraries that do almost basically the exact same thing. Not to mentioning managing back and forth. What do you think? I’m going to submit the bindings to sourceforge, you can add the installer/interface files it to your cvs from there. Tell me what you think, I’ll upload it to sourceforge if this sounds good to you. :slight_smile:

hmm - that’s an interesting (and challenging) question.

are those changes going to be coded in python or in c++ that is wrapped by python? that 's a big difference, because if you going to be coding stuff in C++, we’d be happy to talk about bringing those changes / additions into what we are doing.

I’m pretty sure that we would at least like to release binding for OF with OF, since as we change OF, we will need to change the bindings and it makes sense to think of it like another compiler / platform (codewarrior, devc++, vs, python) that gets updated simultaneously with OF changes.

I need to ping theo about this, and maybe we can figure out the best way to progress…

thanks!!
zach

[quote author=“zach”]hmm - that’s an interesting (and challenging) question.

are those changes going to be coded in python or in c++ that is wrapped by python? that 's a big difference, because if you going to be coding stuff in C++, we’d be happy to talk about bringing those changes / additions into what we are doing.

I’m pretty sure that we would at least like to release binding for OF with OF, since as we change OF, we will need to change the bindings and it makes sense to think of it like another compiler / platform (codewarrior, devc++, vs, python) that gets updated simultaneously with OF changes.

I need to ping theo about this, and maybe we can figure out the best way to progress…

thanks!!
zach[/quote]

I will be coding the base in C++ and some of the more less intensive tasks (where C++ has no benefit) in python. The python stuff can be easily converted to C++ if you guys like. The project I’m starting calls for alot of customization so I guess its a good idea to keep them seperate, but I believe the customizations are good changes. So I guess two seperate bindings is the way to go. I would love to collaborate and share the C++ changes with you guys.

ok cool -

I discussed this with theo and we are not comfortable at this moment supporting a fork – it’s open source, the point is that you can do whatever you want to, but we think that taking the OF code and forking it in another direction (ie, OF+python vs OF) is a bit antithetical to what we are trying to achieve and to be honest, the idea of it doesn’t make us that happy because we have been working very hard to help create a community of users and launch this project, which has taken a mad amount of time and energy. Any splits / branches at this point (when we are just getting things rolling - getting the website and documentation together, going public etc) seems like a rough step. I have to admit that it makes us a bit sad - we expect that folks like yourself that have energy to make changes would instead be interested in adding to OF, in the form of addons, changes, bindings and so on and to see this project as your own. Our goal is to create an open, malleable platform for folks — that’s the whole point of addons (which we are developing now, and where folks for example have added OSC, objLoading, opencv, xml, etc) and the point of coding it in simplified c++ (avoiding fancy, esoteric coding styles) and of the code being uncompiled, always in front of you. Granted it’s taking a long time, alot longer then we thought or would like, but we are trying to create a quality product on all platforms and to develop a self sustaining community of people that are using and hacking with it. We are also doing alot of workshops and teaching and tryign to help beginners, as well as doing the work that brings the $, so it’s a balance.

that said, if you want to want to do two projects, do whatever you feel is right, no one is going to stop you. We’d only hope that you would consider what you want to - those customizations, optimizations and additions as something that you could do within the umbrella of this project.

thanks again for doing the python bindings – it was really amazing for us o see that it could be done, and it give us (and other folks) alot of hope for different possibilities.

take care,
zach

Hi ech0

In the opensource world it’s considered really nasty to branch a project if it’s not absolutely necesary. Zach has pointed most of the reasons.

When someone makes a different project from an existing one, it’s normally because a lack of participation from the original developers, lack of community or some features that the original developers don’t want to have in the project since they are more mature and indeed those cases are really strange and in most of that situations the fork will join to the original project once that problems are solved. Take a look for example at the compiz/beryl case or Cinelerra one. In fact the only case of a permanent branch that I know is the joomla/mambo case where the original developers decided to not continue the project as GPL and make it comercial.

In fact you can do what you want as far as the project is free, but take a look for example at the forum and you will see the degree of implication in the project from Zach, Theo and many other people.

Also branching will make it dificult for you to mantain up to date your mods and to incorporate new features from the original project.

[quote author=“zach”]ok cool -

I discussed this with theo and we are not comfortable at this moment supporting a fork – it’s open source, the point is that you can do whatever you want to, but we think that taking the OF code and forking it in another direction (ie, OF+python vs OF) is a bit antithetical to what we are trying to achieve and to be honest, the idea of it doesn’t make us that happy because we have been working very hard to help create a community of users and launch this project, which has taken a mad amount of time and energy. Any splits / branches at this point (when we are just getting things rolling - getting the website and documentation together, going public etc) seems like a rough step. I have to admit that it makes us a bit sad - we expect that folks like yourself that have energy to make changes would instead be interested in adding to OF, in the form of addons, changes, bindings and so on and to see this project as your own. Our goal is to create an open, malleable platform for folks — that’s the whole point of addons (which we are developing now, and where folks for example have added OSC, objLoading, opencv, xml, etc) and the point of coding it in simplified c++ (avoiding fancy, esoteric coding styles) and of the code being uncompiled, always in front of you. Granted it’s taking a long time, alot longer then we thought or would like, but we are trying to create a quality product on all platforms and to develop a self sustaining community of people that are using and hacking with it. We are also doing alot of workshops and teaching and tryign to help beginners, as well as doing the work that brings the $, so it’s a balance.

that said, if you want to want to do two projects, do whatever you feel is right, no one is going to stop you. We’d only hope that you would consider what you want to - those customizations, optimizations and additions as something that you could do within the umbrella of this project.

thanks again for doing the python bindings – it was really amazing for us o see that it could be done, and it give us (and other folks) alot of hope for different possibilities.

take care,
zach[/quote]

I am sorry you feel that way. The reason I want to branch out is because I want to start an application. A flash like platform for the interactive artists who need more then what flash can currently provide (opencv, live audio/video manipulation/effects, 3d, etc, etc). I do not mean disrespect. The reason it has to be a branch is because C++ is compiled, and the project I’m doing would rely on the language being interpretted. I would support your project all the way throughout the process submiting changes. I think an application like this can only help boost your project and not hinder it. I can actually work with you guys and submit all changes. another reason I was thinking about branching out was because I don’t know if I would have the freedom to make the changes I want to make. I hope you understand, I do not mean to belittle your work, what you have done is great. This project is quire different and I think will be very useful to this field of art.

i’d like to support zach’s opinion here. i also don’t see a reason to branch. why don’t you give it a try and work with original OF as long as it is possible for your application?
i submitted a couple of changes and zach was always open for my suggestions. why should it be different with your suggestions? i don’t see what radical changes would be necessary for an interpreted approach. all python wrappers i know just use the original libraries. even a huge project as wxWidgets gets along without branching.

btw: your idea of something similar to flash sound really intrigueing. i always wanted something like that but open source! flash is really not good enough for artists.

but i guess what we need pretty soon is some versioning system that everybody can use for submitting changes.

best
joerg

[quote author=“jroge”]i’d like to support zach’s opinion here. i also don’t see a reason to branch. why don’t you give it a try and work with original OF as long as it is possible for your application?
i submitted a couple of changes and zach was always open for my suggestions. why should it be different with your suggestions? i don’t see what radical changes would be necessary for an interpreted approach. all python wrappers i know just use the original libraries. even a huge project as wxWidgets gets along without branching.

btw: your idea of something similar to flash sound really intrigueing. i always wanted something like that but open source! flash is really not good enough for artists.

but i guess what we need pretty soon is some versioning system that everybody can use for submitting changes.

best
joerg[/quote]

Perhaps a branch isn’t neccesary, I don’t know… but if the changes I want to make aren’t accepted, then I have no choice but to branch out don’t I? The program I am making calls for alot of optimization and custimization. Some of the functions will be revised, renamed, etc. since i am targeting the web as well. Thats the reason there needs to be a branch. It’s only for the platform, not to start a competing library. If could do this without branching out I would.

Another issue is that I can’t use Glut. I will be embeding the opengl in my application so i have to switch to SDL. Also the web plugin I will be creating will need to use SDL…

ok, here are the python bindings…

http://code.google.com/p/openframeworks-…-loads/list

at the moment it is windows only because I only have access to a windows machine. the swig internface file is in there so if anybody knows how to use swig you can compile it for another platform. I will try to make compilations for other operating systems using vmware when I have the time.

also there is no installer. your going to have to use it from the directory where it exists or drop it into your python site-packages folder.

this will all be remedied soon when i have the time.

[quote author=“ech0”]
Another issue is that I can’t use Glut. I will be embeding the opengl in my application so i have to switch to SDL. Also the web plugin I will be creating will need to use SDL…[/quote]

i was able to use OF in wxPython glcanvas.GLCanvas without disabling glut or anything. so no need for SDL here. i don’t know what you’d like to use as a gui framework but there’s no general need to get rid of glut. if you are interested i could send you the code…
i don’t know anything about web-plugins however.

best
joerg

hi - I have to be super fast, because I have to run. Both theo and I are enthusiastic about your project and would love to help.

many of issues you bring up (ie, making changes to the code, optimization, etc) are completely valid and quite frankly good for the project.

For example, we use glut, but we don’t have to - we’ve actually had OF running on glfw, in wxWindows and likely getting it on SDL wouldn’t be hard. the changes that would have to be made include abstracting the glut specific code (which is primarily in ofUtils) and thinking of cross platform alternatives, either using the other windowing toolkits or cross platform code (for example, elapsed time). Both of those changes would be good ones, because they make the core more flexible.

in fact, the other day, after adding the polygon code to ofGraphics I was cursing glut because of not supporting FSAA, and realized how not up to date the library is, and I actually thought the same thing - we should be able to switch more easily.

Additionally, we could consider even creating separate branches internally - perhaps an optimized OF for people that want to push it to the limit of performance. For example, we do two things with images that are designed to be helpful for people - (a) treat all images as continugous in memory and (b) convert all BGR byte orders to RGB. These two choices, while making it generally easier for users add overhead (for example, ofImage is full of unoptimized code), and we are happy to support a branch of development that takes the OF code and optimizes it completely. We definitely want to create room for experimental collaborative development, because that will ultimately allow people to shape OF in different directions and also have a great impact on the core code that is being shipped.

All of the kinds of conversations we could have about changes / approaches, etc would be really good. there is alot for all of us to learn from one another. Of course we try to be a bit controlling of the core, because we have specific goal about making it easy for people, being transparent, etc, that doesn’t always fit with peoples perspecitves about coding (for example, using templates, namespaces, etc) but that doesn’t mean we aren’t open to modifications, suggestions, revisions, or that we wouldn’t be open to creating experimental versions of OF that try different approaches.

I will respond in more detail when I get a second, but we are going to work hard to both clearly articulate the development goals of OF (ie, why the core is made in a certain way, and what our style / goals are) and also to open up the process as much as possible. We are super, super new to open source and learning immensely as we go - for example, only recently we learned how to properly set up the SVN and now, we are learning how to do multiuser setup.

I have to run - but this conversation is super helpful for us, and we want to make it as useful a project for people from all different levels - from the tinkerers who have never touched c++, to hackers and application developers etc, so this kind of discussion is really important.

take care!
zach

I really do appreciate your response! Thanks. I’m glad you understand. I think we have alot to gain from this and I’m super excited.

btw: take a first look at openframeworks for the web. plugin looks at a file and draws into the browser.

wow - that’s cool !! we are pretty psyched about web stuff - it’s seems pretty incredible that it’s possible. I’m just downloading the python framework now and will give it a try today.

my head is already spinning about the changes that might be necessary for OF in the browser… if you want to open a thread about modifications to OF for the project, I’m sure there are a bunch of folks that would like to chip in with ideas, suggestions, mods, etc. For example, theo and I have been working on loading of objects via URL (ie, using libCurl, etc) as well as by local files, something which might prove useful…

take care !!
zach

[quote author=“zach”]wow - that’s cool !! we are pretty psyched about web stuff - it’s seems pretty incredible that it’s possible. I’m just downloading the python framework now and will give it a try today.

my head is already spinning about the changes that might be necessary for OF in the browser… if you want to open a thread about modifications to OF for the project, I’m sure there are a bunch of folks that would like to chip in with ideas, suggestions, mods, etc. For example, theo and I have been working on loading of objects via URL (ie, using libCurl, etc) as well as by local files, something which might prove useful…

take care !!
zach[/quote]

One of the key issues of enabling web support is security. Java applets have built in security checking so that malicious code doesn’t run on the users computer without permission. If I’m to create a Python plugin I’m gonna have to manage that myself hacking the core python source… i will have to handle security threats, issue security updates. etc. etc. that will take some time… too much work. i can do that or simply run a dangerous "Are you sure you want to run this application dialog. If a user clicks yes and the source contains some malicous code the enduser is fcked. Actually thats how ActiveX works. That is the problem with a python web plugins.

but there is a solution.

I think for Openframeworks the best solution for a web plugin would be the java bindings. These bindings can then be called via Java or get this, Jython!!! You can create Jython applets very easily. Jython and python are almost exactly the same so you should notice no difference in your development. Java takes care of the dirty work, applet runs fine.

I just compiled a java version of the bindings. Of course thanks to swig its that easy. We can create bindings for any of the following languages:
http://www.swig.org/compat.html#SupportedLanguages

Python, Perl, Java, Ruby, C#, Lua… just to name a few.

Also it looks like they are working on javascript support if you look further below in that page.

I know that java bindings are really unnessasary since there is already processing for java, but this is just an idea. Plugin security for dynamic code is a complicated issue and this is just a simple way out. Perhaps a jython version of processing would be the much nicer option. :wink:

Zach, Theo, & ech0,

After keeping an eye on OF for several months, I just had a chance to spend some time with it earlier this week. Coming from Processing and AS3, the speed difference is incredible. Real-time aesthetic excess is at last an option.

I’d never touched C++ before OF, and with a lot of cursing made it through some of the libraries and re-implement a project originally built with Processing. I was intrigued to see ech0’s Python bindings as an alternative for those who don’t number among the C++ masochists.

Are the bindings available for 0.05, and has anyone succeeded in running them on Mac OS?

-Eric