Etienne,
Are these dropped frames your seeing a result of rotating the object via numberbox/PD GUI or from another machine running over -nogui? I ask because the PD gui is known to have issues and it is easily possible that it is the number box causing this problem and not Gem. Try sending a signal from python over a local socket to pd/Gem running in -nogui. Does it do the same thing?
I'll have to test things on my new linux machine when I get it, but I hope what your saying is not evident. I don't see this happening on OSX. Do you have a test patch?
Disappointed B.
:(
Etienne Desautels wrote:
Hello,
On 05-06-05, at 17:14, Tim Blechmann wrote:
hi all ...
Also, what I would really prefer is to had support in Gem for LibMPEG2. Do you think it could be difficult to do ? Is it about creating a filmMPEG2.cpp and filmMPEG2.h files with the good function calls to the library and add the reference into the pix_filmNEW.cpp ?
correct. if you like to add libMPEG2-support you are welcome!
stupid question, but what about mplayer support instead of libMPEG2? mplayer is able to play back about every file format ...
just thinking loud ... tim
I know, it would be wonderfull...
But Mplayer is not a library. You can only use it as an application. Mplayer itself use LibMPEG2 to play MPEG2 stream and use other libraries for other formats and codecs (as FFMPEG, XVID, etc).
Unfortunately, I will not add LibMPEG2 to GEM. In fact I'll not use PD/GEM at all for the big project I'm working on. Maybe I'm crazy but the problem is that PD is not multithreaded and work with CPU time and not real time. So if you try in Gem to do something as simple as rotating a square on the screen, it will not rotate regularly. It will stall from time to time. And if you try to load a big texture (1024x1024) the rotation of the square will stall even more badly. And I don't think there's something I can do ? I tried to preload some big textures with pix_buffer but when I display the image it's sucking a lot of CPU. When I say a lot I mean a lot. The more your texture is big the more CPU it's suck. It's very strange. I don't understand why? Anyway, in the mid-term it's not an option for me to preload the images. So now I'm doing the project in Python with pyOpenGL. This way I can schedule redraw in real time, not cpu time, and open my textures in a thread. This way everything play smoothly. But I have a lot more to code ! I wish I could done it with PD/GEM but it's not possible.
One last note: for FFMEPG in Gem, I did try so many things but in the end it never worked. I always have the -2 error meaning that there's an I/O problem?
Anyway thanks for your good work to all the developers of PD and Gem !
Etienne