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 wrot
On Tue, Dec 11, 2012 at 1:48 PM, IOhannes m zmölnig 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 enoug
On Sat, Nov 24, 2012 at 7:52 AM, Jack wrote:
>
> >> Seriously, as Chris says it's better to use shaders now, it's more
> >> flexible.
> > i do not agree.
> > using shader, how would you do :
> > GL_ONE_MINUS_SRC_COLOR
> > you need the source color. a readback is not an option.
> In my mind i was
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 wrote:
>
>
> Le 21/11/2012 15:
On Tue, Oct 23, 2012 at 11:42 AM, Hans-Christoph Steiner wrote:
>
>
> Hmm, Max and the web were created on NeXTSTEP because it was such a great
> media environment. There definitely was a shift to consumer side at Apple,
> but Apple was always much more consumer focused than NeXTSTEP. The base
>
On Tue, Oct 23, 2012 at 10:44 AM, Hans-Christoph Steiner wrote:
>
>
> 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 us
On Tue, Oct 23, 2012 at 10:18 AM, Hans-Christoph Steiner wrote:
> > as chris has pointed out, it's probably better to drop mpg support on
> > OSX, rather than trying to fix it (esp. since i don't have too much
> > time right now).
> >
> > it _is_ a regression, but with a low priority.
>
> I think
On Oct 16, 2012, at 12:05 PM, Hans-Christoph Steiner 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
>
>
>
> ___
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 wrote:
>
> There is an outstanding bug where many videos don't play with Gem. Right
> now, this bug in Gem is
On Thu, Jul 19, 2012 at 6:14 AM, Theo Burt wrote:
>
> Does anyone know how the vsync works on OSX? I mean how does GEM wait for
> the vsync, to flip the buffer? Does it block the process at any point? Is
> the process blocked by any part of GEM at any point, on a per frame basis?
>
VBL sync is a
On Tue, Jul 17, 2012 at 5:59 PM, Cyrille Henry 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 n
On Tue, Jul 17, 2012 at 5:35 PM, Cyrille Henry 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
>
On Tue, Jul 17, 2012 at 5:09 PM, Jack 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
Sounds like a driver problem. I recall putting in some sort of reset
message and along with sending new dimensions it would pretty much work
like instantiating pix_video again. But the nature of Quicktime might not
allow for an app to recover a device that drops out without either
restarting the
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 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 2012-02-04 17:23, dmotd wrote:
> > it makes sense to resurrect so
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 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 2
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 wrote:
>
> On Apr 6,
On Tue, Mar 22, 2011 at 9:26 AM, Hans-Christoph Steiner wrote:
>
>
> 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,
> b
ome 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 wrote:
> On Mon, 14 Feb 2011, chris clepper wr
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
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 wrote:
> I know, this is not a s
When has it not?
On Mon, Jan 24, 2011 at 9:59 AM, wrote:
> I am surprised to see [FSAA( works with ATI graphic cards (5770) on
> MacPro and MacOSX.6.4.
> Using Pd-ext 0.42.5 and GEM 0.92.3.
> ++
>
> Jack
>
>
>
>
> ___
> GEM-dev mailing list
> GEM-dev@i
The Blackmagic Intensity has Linux drivers and captures uncompressed analog
or HDMI signals. It is not supported directly by V4L, so you would have to
do some programming to get it working.
It is a nice card for the money ($199) though.
On Tue, Aug 3, 2010 at 5:55 PM, B. Bogart wrote:
> Hey
On Tue, Apr 6, 2010 at 9:17 AM, IOhannes m zmoelnig wrote:
> (i usually don't use xcode, so that's why the project file is not being
> updated accordingly; sorry for that)
>
>
I don't blame you since XCode is kind of a disaster. It eats 3GB of RAM and
two CPUs when I compile GEM - that's the IDE
On Tue, Apr 6, 2010 at 9:17 AM, IOhannes m zmoelnig wrote:
> On 2010-04-06 14:57, chris clepper wrote:
> > But all of the QT code is wrapped with HAVE_QUICKTIME, and in at least
> one
> > case it looks like HAVE_CARBONQUICKTIME undefines HAVE_QUICKTIME.
>
> cannot reprod
On Tue, Apr 6, 2010 at 9:17 AM, IOhannes m zmoelnig wrote:
> that's weird; i compile Gem on 10.5 with autoconf quite often (and it's
> used with the autobuilds as well) and it works stable.
> my exact call to configure (including all the user-built statically
> libs) can be found here:
> http://g
10-04-02 00:46, chris clepper wrote:
> > Hi
> >
> > I don't know what the HAVE_CARBONQUICKTIME is all about, but it broke all
> of
> > the QT code on the Mac because it does not actually enable any QT code at
> > all! I am trying to build on 10.5, and obviously
Hi
I don't know what the HAVE_CARBONQUICKTIME is all about, but it broke all of
the QT code on the Mac because it does not actually enable any QT code at
all! I am trying to build on 10.5, and obviously pix_film/video/record do
nothing now. I guess this is in place in order to build on 10.6? Wh
Sisti Sette <
matteosistise...@gmail.com> wrote:
> chris clepper escribió:
>
>
> OpenGL absolutely allows for platform specific behavior,
>>
>
> Wow, really sad
>
>
>
> --
> Matteo Sisti Sette
> matteos
On Thu, Mar 18, 2010 at 11:23 AM, Matteo Sisti Sette <
matteosistise...@gmail.com> wrote:
>
> Does the OpenGL standard allow for some differencies between
> implementations in the way texture coordinates are treated, or is it safe to
> state that if the same patch with the same shaders gives diffe
Ben
I don't see how setting a max number to grow to is any different than
allocating N number of frames to begin with. GEM only grabs memory when you
put an image into a slot the first time or replace one with a different
size.
So you can do [pix_buffer biggie 1] and only use 500 frames with
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 co
Try the Apple suggestion first, and then the others?
I also never got anything out of the artoolkit object.
On Fri, Dec 4, 2009 at 12:24 PM, Hans-Christoph Steiner wrote:
>
> So I installed artoolkit from Fink, and Gem gives this build error, which
> is new to me. Is it worth trying to get arto
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 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.
>
> Ho
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 wrote:
> Hi,
> Something I would add to G.E.M. is the "Depth Of Field" effect.
> Someone aske
On Wed, Oct 7, 2009 at 12:42 PM, Hans-Christoph Steiner wrote:
>
> 64-bit Gem on Mac OS X could drop Quicktime/Carbon in favor of gstreamer
> and/or gmerlin which I believe is already implemented on GNU/Linux.
>
That would throw away the advantages of QT on OSX, and I would probably no
longer use
> x86_64): Mach-O 64-bit dynamically linked shared library x86_64
>
>
> .hc
>
> On Oct 7, 2009, at 8:18 AM, chris clepper wrote:
>
> GEM uses Carbon which is not 64 bit. Most apps (Photoshop, ProTools, etc)
> on OSX have no path to 64 bit without a nearly complete rewrite.
>
GEM uses Carbon which is not 64 bit. Most apps (Photoshop, ProTools, etc)
on OSX have no path to 64 bit without a nearly complete rewrite.
On Wed, Oct 7, 2009 at 12:20 AM, Hans-Christoph Steiner wrote:
>
> Why not?
>
> .hc
>
> On Oct 6, 2009, at 4:54 PM, chris clepper wrote:
It never will be 64 bit on OSX.
On Tue, Oct 6, 2009 at 4:26 PM, Hans-Christoph Steiner wrote:
>
> For this upcoming Pd-extended 0.42 release, we should start releasing
> 64-bit builds. Is Gem in 64-bit ready for prime time?
>
> .hc
>
>
>
>
On Tue, Aug 25, 2009 at 5:02 PM, B. Bogart 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
On Sat, Aug 15, 2009 at 6:25 PM, Jack 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 kn
On Sat, Aug 15, 2009 at 5:05 PM, Jack wrote:
> I have tried to convert my movie with VLC to .mov (M-JPEG) and all works
> fine now :) Thanx for your reply Chris.
> 'M-JPEG' on Linux and 'Photo JPEG' on MacOSX are equivalent ?
> ++
>
Motion-JPEG is interlaced (2 fields per frame) and Photo-JPEG i
Have you checked RAM and hard disk usage while playing the movies? Is it
just a specific part of certain clips that slow down or do all clips do it?
On Sat, Aug 15, 2009 at 1:32 PM, Jack wrote:
> Hello,
>
> I come back with my problem.
> I try different option on the nvidia driver (180.44) in t
; 16 in any cases or not ?
> I use the last NVidia driver 180.44 on Ubuntu 9.04.
> ++
>
> Jack
>
>
> Le 24 juin 09 à 16:32, chris clepper a écrit :
>
> On Wed, Jun 24, 2009 at 8:53 AM, Jack wrote:
>
>>
>> However, there is something very strange if it's
On Wed, Jun 24, 2009 at 8:53 AM, Jack wrote:
>
> However, there is something very strange if it's about memory because on my
> MacPro 2x2.66 GHz Dual-Core Intel Xeon, i have only 256 MB on the GPU and
> all works fine on it (only 2 fps but it is not so slow).
> The size of the images are between
I think gemframebuffer replaced that code. Perhaps delete the file?
On Thu, Jun 18, 2009 at 1:35 PM, Hans-Christoph Steiner wrote:
>
> On Mac OS X 10.4/intel
>
> g++ -c-I/sw/include -I/sw/include/FTGL -g -O2 -fPIC -freg-struct-return
> -Os -falign-loops=32 -falign-functions=32 -falign-jumps=
This problem for a DV cam is new to me. I have beat the living shit out of
that code for years with no problem. Quicktime has gone seriously downhill
the past few years for no reason other than the Cocoa guys can't program to
save their lives. File a bug with Apple, address it to Peter Graffagni
A video file is just a container for sequences of images. Quicktime movies
can be a series of Tiff or PNG or raw RGBA images. The solution I gave you
will work if you bother trying it.
On Wed, May 20, 2009 at 9:00 AM, johann scholz wrote:
> hi,
>
> thx for the answer but the problem is that i
The size on disk doesn't matter because when the images are loaded they are
decompressed to 32 bit RGBA in RAM. 100:1 compressed or uncompressed images
will be the same size in RAM.
You can try making a single Quicktime movie out of the image sequence using
QTPro, and loading the movie into RAM.
On Tue, May 12, 2009 at 5:12 PM, Roman Haefeli wrote:
>
>
> i see. thanks for the explanation. one reason, why i was thinking, that
> gem doesn't use hw acceleration was that the cpu power used is quite
> similar to the ones, when the same file is played by mplayer or vlc. but
> according to what
The video might be using hardware acceleration for the h.264, but getting no
benefit. Quicktime player just displays the movie and nothing else, while
GEM requests the fully decoded pixels in RAM. The video might be getting
uploaded to the GPU, decoded, then bounced back to RAM and then uploaded
The GEMgl objects really require a working knowledge of OpenGL, and it would
be a bit much to redo much of the standard texts in the help patches. Just
put a link to: http://www.glprogramming.com/blue/
That should cover most of the objects - even the ones that can't possibly
work in Pd/GEM.
On M
I always had problems with the IOXperts driver. Can you uninstall it and
try using the Apple IIDC driver?
On Sat, Mar 21, 2009 at 1:12 AM, adrian goya wrote:
> Hello.
>
> I found this old thread while searching for a solution to my problem.
> http://lists.puredata.info/pipermail/gem-dev/2008-11
53 matches
Mail list logo
