Re: [GEM-dev] AVFoundation status
Don't worry, in a couple of years or less the AVFoundation will be dead and you will have the pleasure of writing it all again from scratch. And it will be much less reliable and lower performing to boot. Apple can never leave well enough alone! On Mon, Feb 24, 2014 at 9:58 AM, Dan Wilcox danomat...@gmail.com wrote: Howdy all, I have filmAVFoundation basically written. It loads in Pd-0.45-4 64bit, but I haven't tested it yet. I decided to go with AVFoundation when my first attempt using QTKit resulted in plenty of compiler deprecation warnings. It turns out QTKit is deprecated in Mac OSX 10.9 and will disappear in the next release or two. I've updated the build system to handle the ObjC files and it appears to be working, although I did some quick hacks to remove the quicktime checking so I'll need to clean that up before I push nay of the code to Github. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] pix_set new features
On Tue, Dec 11, 2012 at 1:48 PM, IOhannes m zmölnig zmoel...@iem.at wrote: one could provide helper-functions to easily convert a given ROI/pix to absolute coordinates on the C++ layer, if you care about the programming overhead. the computational overhead is small enough. It should be easy enough to do this on the patcher level with pix_info, pix_film outlet etc. right? ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] Different Alpha Blending Methods in Alpha Object
I really thought Jamie added all of that a long time ago. I know I had versions with all (or most) of the blend modes. Obviously, shaders make it kind of obsolete, so I probably never used the modes after 2006 or so. On Thu, Nov 22, 2012 at 7:45 AM, Cyrille Henry c...@chnry.net wrote: Le 21/11/2012 15:02, Jack a écrit : Le 20/11/2012 18:52, Santi a écrit : Hello, i don't know if this is the right place to write, sorry if don't. I'm working in a project with PD/Gem and i need more blending methods than the original Alpha object has. I've modified slightliy the file alpha.cpp (see atachment) and recompiled Gem. Simply i've add the different OpenGL blending mehods to the switch in the function funmess(). Some are working in mi system (Debian Wheezy), others are the same output than GL_ONE. I like specially GL_ONE_MINUS_SRC_COLOR, it doesn't saturate the bright pixels like GL_ONE_MINUS_SRC_ALPHA does. My question: Is there any reason to not include different alpha blending methods? the modification i've made is very simple and obvious, so i'm thinking about why not had made before... do i have lost something? Regards and sorry for my english... Santi Noreña __**_ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/**listinfo/gem-devhttp://lists.puredata.info/listinfo/gem-dev Hello, You can use the object [GEMglBlendFunc]. yes, but i don't see any reason not to include it in the alpha object. cheers c ++ Jack __**_ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/**listinfo/gem-devhttp://lists.puredata.info/listinfo/gem-dev __**_ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/**listinfo/gem-devhttp://lists.puredata.info/listinfo/gem-dev ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] [ pd-gem-Bugs-3517368 ] gem 0.93 does not play .mpg files on Mac OS X
On Tue, Oct 23, 2012 at 10:44 AM, Hans-Christoph Steiner h...@at.or.atwrote: You've captured the problem with Apple these days in a nutshell. Seems like they are going Final Cut X on everything, or worse: its all about selling stuff in iTunes, and everything takes a back seat to that. After using NeXTSTEP/Mac OS X as my primary OS since 1995 (I was that weird guy with a NeXTSTEP/i386 box at work in 1998), I will never upgrade past Mac OS X 10.6, and these days I'm in Linux Mint 80-90% of the time. But ultimately, while I'm sad to see NeXTSTEP end like this, I'm happy Apple is going this route because that means they will drive away the people with skills, and send them to free software :) I'm planning on getting involved in etoile/GNUstep to help build a better NeXTSTEP that is also free. Not to get too sidetracked, but it was the Nexties that killed off Quicktime because they did not understand the first thing about media arts. After the Jobs/Next reverse takeover of Apple the shift was from art to industrial design (and consumer marketing). It was a constant source of frustration for the people working on what was previously Apple's core market. I heard repeatedly from those people at Apple that 'management doesn't get art'. ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] new libraries on Mac OS X
On Oct 16, 2012, at 12:05 PM, Hans-Christoph Steiner h...@at.or.at wrote: Ok, all of these are installed except for freeglut. Let me know if you think freeglut should also be there. Mac OS X does seem to come with its own glut. Sure it does it's part of standard opengl .hc ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] any word on the Mac OS X 1 frame video bug
Quicktime always reports MPEG-1 as a single frame movie, so that's unlikely to change. Are videos other than MPEG-1 not playing? On Fri, Sep 21, 2012 at 11:40 AM, Hans-Christoph Steiner h...@at.or.atwrote: There is an outstanding bug where many videos don't play with Gem. Right now, this bug in Gem is the only thing holding back the final release of Pd-extended 0.43.1. http://sourceforge.net/tracker/?func=detailaid=3517368group_id=64325atid=507079 Is there a fix for it that I can include in the Gem version included in Pd-extended 0.43.1 (the most recent Gem release). .hc ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] Problem with glitching on OS X at high frame rates
On Tue, Jul 17, 2012 at 5:09 PM, Jack j...@rybn.org wrote: If you have Gem at 100 fps and you screen at 60 fps, you should encounter a problem of sync at a certain moment, no ? If not, can you explain more ? Maybe the best is when you have Gem fps as a multiple of your screen fps ? Thanx for the rest of explanation. ++ The GPU has at least two buffers for drawing to screen. The back buffer is where all of the rendering is done and the front (or display) buffer just gets a copy of the back buffer at a specified interval. The idea is that rendering can take a long time while a copy cant be done quickly (GPU VRAM copies are insanely fast now), so you can take almost all of the render time to draw the frame then swap buffers at the last instant and then go back to rendering. I initially set the OSX version of GEM to VBL sync to remove the 'tearing' artifacts that horribly plagued other software (Nato advertised it as a feature). I wanted smooth HD video regardless of GEM render rate and used VBL sync and async texturing to do it (this also ended up in the VLC GL rendering code on OSX that I advised on a long time ago). Using VBL sync will only flip the back buffer to the front at 60 fps. It should be possible to feed GL and the GPU more data than the 60 FPS you need but it might not be displayed. Or maybe the results will be indeterminate? It could be back to the tearing issue if the back buffer is partially filled at swap time. I used to know all of the guys who wrote the Mac drivers and made the ATI chips, but we have all gone on to other things, so I can't get a definitive answer right now. ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] Problem with glitching on OS X at high frame rates
On Tue, Jul 17, 2012 at 5:35 PM, Cyrille Henry c...@chnry.net wrote: if you ask Gem to render at 100Fps, you'll have a new image 10ms after last render. if your screen is rendering at 60fps, it ask for 16.6 ms between 2 images. so, after having render a frame, gem will wait for the scren 6.6ms on average. everything will be hang during this 6ms. pd time will desincronize from real time. that's why the clock from this pd can not be used to compute audio. but since pd timing is more than 6ms acurate, you can be certain that every computed frame will be rendered for 16.6ms So this result on using a timing based on the screen. you can use this pd the send bang to an other pd that compute the sound. There could be locks on the back buffer when using VBL sync that would prevent anything more frequent than 1/VBLrate to actually render into it. So you might have a situation like this: render 10ms wait 6.6ms render 3.4ms render 10ms wait 3.3ms to get two frames. As I wrote previously, I used to know who to ask to get the actual answer to this, which was great because the GPU people are really secretive about their black boxes. ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] Problem with glitching on OS X at high frame rates
On Tue, Jul 17, 2012 at 5:59 PM, Cyrille Henry c...@chnry.net wrote: oh, on linux you can't render faster than the screen. i supposed that it was the same on osX, but i'm may be wrong. if you can render faster than the screen, then the proposed solution will not work, and i have no other solution, and no explanation for the problem. GEM is certainly sending the GL commands at whatever rate you set, but I honestly don't know for sure what happens in the GL driver and on the GPU when setting the GEM frame rate higher than VBL sync. Maybe the extra rendering commands are ignored or maybe not. ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] vertex operations / vertex_* (prev.. gem port to opengl-es - initial developments..)
Go ahead and remove it. It was abandoned when it became clear the VBO option with shaders is the better solution. On Mon, Feb 6, 2012 at 8:35 AM, IOhannes m zmoelnig zmoel...@iem.at wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-02-04 17:23, dmotd wrote: it makes sense to resurrect some of vertex_* code and clean it up, although i'm a little hesitant about working with it directly as it has personally i would like to get rid of it entirely - i simply haven't had the heart yet to do so... i think a simpler approach is taken using the new [gemvertexbuffer] object (by cyrille and antoine), which basically allows to use a table as VBO input. shouldn't that be enough for your needs? most Geos could be implemented as an abstraction based on [gemvertexbuffer] (who's first?) fgmadsr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8v1wEACgkQkX2Xpv6ydvSG9wCfXLMG58NwJCVEumrpuDVzzBgC fkUAnjlVVK07gTQKmanSSrSURqqMNE4b =xrgn -END PGP SIGNATURE- ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] Frame rate on MacOsX
GEM is synced to the VBL of the display which is 60Hz. I can't remember if I put a VBL sync disable message in the gemwin code or not. On Mon, Nov 21, 2011 at 1:53 PM, Jack j...@rybn.org wrote: Hello, I am working on an installation on MacOsX.6.7 with Pd-extended 0.42.5 and Gem 0.92.3 (compiled Sep 22 2010). The graphic card is a ATI Radeon HD 5770. On this environment, i can't get a stable frame rate. With [gemwin 50], i get sometimes with the abstraction [realFPS] : 60 fps (strange no ?) then 5 seconds after 40 fps. Even when the scene is the same. How can i obtain 60 fps when it is write [gemhead 50] ? Someone has a similar problem ? How can I fix it ? Thanx. ++ Jack __**_ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/**listinfo/gem-devhttp://lists.puredata.info/listinfo/gem-dev ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] film/video not working on OSX (was Re: videoKINECT plugin for pix_video)
I just tried the nightly from 4/1/11 and it looks like the problem is pix_texture. The movie was playing judging by the change in CPU load. Also, I could load one image with pix_image, but after that texturing went awry. On Wed, Apr 6, 2011 at 4:01 PM, Hans-Christoph Steiner h...@at.or.atwrote: On Apr 6, 2011, at 3:32 PM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-03-26 12:40, Matthias Neuenhofer wrote: what does not working mean (apart from 'not working')? pix_film reports correct size and length on loading and i understand that this means, that [pix_film] reports everything right, and still does not display an image pix_video turn the internal isight on but the texture stay white. (it's a bit unclear whether those are 2 separate sentences or not) in any case: i downloaded the latest build of Pd-extended for OSX, and haven't seen any problems with loading a test movie. i also compiled a recent svn version of Gem with plugin support on OSX, and the test movie showed nicely. i now just realized that the latest Pd-extended seems to be some stable thing, as it contains Gem-0.92.1. downloads take forever, so i can only try a 20110406-macosx104 version tomorrow. i was not able to test [pix_video], as my powerbook does not have a built-in camera. ah yes: OSX/10.5.8, G4 Here's the bug report: https://sourceforge.net/tracker/?func=detailaid=3277839group_id=64325atid=507079 .hc If you are not part of the solution, you are part of the problem. ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] videoKINECT plugin for pix_video
On Tue, Mar 22, 2011 at 9:26 AM, Hans-Christoph Steiner h...@at.or.atwrote: Yes, it would be nice to have [pix_video] work with the Kinect, but right now the plugins stuff is not fully done yet, and people want to work with the Kinect now. I tried to get stuff building using the Gem build system, but I couldn't get it going, so I just made a Makefile which seems to work. For one, it seems to depend on automake-1.11, which is not always easily available. I see no reason why the Gem plugins can work for automake-1.9 or even earlier, its not a complicated build. On the Mac and Windows the proper way to do this is to make Quicktime components or DirectShow filters so any application can use the device. Writing specific app level code for every random video device is a waste of time. ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] [pix_video] osx (fwd)
The messages are different on OSX because devices can and do have multiple inputs. Selecting a 'device' only is not enough information to tell the driver of something like a Blackmagic Intensity card so you need to add an 'input' message as well. On Mon, Feb 14, 2011 at 9:47 AM, Mathieu Bouchard ma...@artengine.cawrote: -- Forwarded message -- Date: Mon, 14 Feb 2011 08:43:11 -0500 (EST) From: Mathieu Bouchard ma...@artengine.ca To: IOhannes m zmoelnig zmoel...@iem.at Subject: [pix_video] osx Did you know that in gem 92, the device method of [pix_video] seems to have no effect ? I had to use two [pix_video] : one to force opening of the first camera, and one to get the other first remaining camera. It looks really weird. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] [pix_video] osx (fwd)
Many video capture devices have multiple physical inputs and some manufacturers use and input to set things like PAL/NTSC or colorspace or even resolution. The only way to really figure it out is with the 'dialog' window. It is kind of a pain to configure certain devices and some of the pix_videoDarwin code contains workarounds so I could do plug and play installations all over the world. I thought I added this to a help file long ago in a Mac specific subpatch. Maybe not. On Mon, Feb 14, 2011 at 12:56 PM, Mathieu Bouchard ma...@artengine.cawrote: On Mon, 14 Feb 2011, chris clepper wrote: The messages are different on OSX because devices can and do have multiple inputs. Selecting a 'device' only is not enough information to tell the driver of something like a Blackmagic Intensity card so you need to add an 'input' message as well. ah, an input method is indeed defined in pix_videoDarwin.cpp, but it is not mentioned in pix_video-help.pd (of gem 92), and I have no hint that something is to be done. This behaviour of device is also contrary to [pix_video]'s construction-time behaviour of pick the first video stream we can find. I'm all in favour of a more manual camera control (so that the user chooses whether to open a camera at all), I'm just pointing out that device/input doesn't seem to be very consistent with [pix_video]'s defaults. BTW, which devices have several inputs on them, in a way that counts as input here (and not multiple devices) ? I'm curious. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] AA with shader
Jack You could try a shader that does edge detection and above a certain threshold apply a simple blur. That should give some sort of AA. A more complex version could adjust the blur based on how strong the edge is. Chris On Tue, Jan 25, 2011 at 6:34 PM, Jack j...@rybn.org wrote: I know, this is not a specific GEM problem. I would like to get the render (started with only geos) from the [gemframebuffer] anti-aliased. And I was wondering if someone has worked on a shader to get this effect and if this person would like to share his shader or to help in development ? Thanx. ++ Jack ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] QTKit instead of Quicktime for 10.6?
It won't make GEM 64 bit because the OpenGL window code is all Carbon. Plus, Quicktime is far from 64 bit clean - there isn't a 64 bit Final Cut Pro for example. Apple has completely fucked up Quicktime, and they don't seem to have a clue as to how to fix it. I do plan on adding some CoreVideo code to pix_movie/film at some point, which should help compatibility. On Sun, Dec 13, 2009 at 1:56 PM, Hans-Christoph Steiner h...@at.or.atwrote: It seems that Apple has a similar API to Quicktime called QTKit that is 64-bit compatible. Would this work for Gem? http://lists.apple.com/archives/quicktime-api/2009/Sep/msg00021.html .hc Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you. - Richard M. Stallman ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] Way to get gemframebuffer back onto main memory for pix_ operations?
Ben This would be a good use for a shader. Much faster to do that way and a good way to get into GLSL too. On Thu, Nov 26, 2009 at 9:51 PM, b...@ekran.org b...@ekran.org wrote: Hey all, I'm rendering data into a framebuffer, but want to be able to pix_add that texture with a live video input. How can I get a gemframebuffer image from texture space into pix_ space??? Thanks, B. Bogart ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] Depth Of Field
This can be done with a shader and a framebuffer. The gemwin is not the way to do it because it knows nothing of the geometry being rendered elsewhere in a patch. On Mon, Nov 9, 2009 at 6:43 AM, Pierre pie...@314r.net wrote: Hi, Something I would add to G.E.M. is the Depth Of Field effect. Someone asked this last year on pd-list without succes/response : http://lists.puredata.info/pipermail/pd-list/2008-10/065649.html Adding something like a 'focus' parameter to [gemwin] would be very nice. Maybe it could be done using GLSL or [GEMglAccum] (*) but, until now, all my searches and tests have failed... Any ideas on how to do that ? I can code a bit a opengl/c, but I have poor skills... So any help, link or idea is welcome ! Best regards, Pierre (*) http://www.opengl.org/sdk/docs/man/xhtml/glAccum.xml (*) http://www.opengl.org/resources/code/samples/redbook/dof.c ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] Playing HDV video with frame accurate seeking on Linux
On Tue, Aug 25, 2009 at 5:02 PM, B. Bogart b...@ekran.org wrote: One thing that is clear is that the CPU overhead is too high, but the disk usage very very low. I'd rather balance things out to use more disk IO to save decoding cycles. That is the key to all codecs. Uncompressed doesn't require CPU to decode but the disk requirements can be very high. Delivery codecs like MPEG and H.264 are the reverse situation. Use a JPEG based or professional capture codec like DVC whenever possible. ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] problem to play movies at normal speed with GEM objects
On Sat, Aug 15, 2009 at 6:25 PM, Jack j...@rybn.org wrote: So the comportment is the same under GEM ? It really depends on the OS and API used to decode the video. Quicktime has similar performance using either Motion or Photo JPEG, and ffmpeg treats them equally well in Windows using FFDShow. I don't know if libquicktime is handling these codecs on Linux or not. But it is better to use Photo-JPEG for scratch video for example (sending a float in the second inlet) ? Use Photo-JPEG for non-interlaced sources and Motion for interlaced. Or deinterlace before converting to Photo. ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
