Re: [GEM-dev] AVFoundation status

[Chris Clepper]

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  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

[chris clepper]

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 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

[chris clepper]

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 thinking about textures operations with the use of two
> framebuffers if you need to capture the scene.
> With this solution, you can determine the source and destination in your
> fragment shader (as glBlendFunc) then operate on destination something
> equivalent to GL_ONE_MINUS_SRC_COLOR, or i miss something and i am wrong ?
> If this solution is OK, you needn't readback...
>
>
That is essentially what recent GPUs do internally for blending anyway.
 There hasn't been a fixed function hardware pixel pipeline for some time
now.  It is more complicated to do for simple geometry in a GEM patch, as
Cyrille points out so it's good to have the 'old' way for that.
___
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

[chris clepper]

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: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-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-dev
>>
>>
> __**_
> 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] [ pd-gem-Bugs-3517368 ] gem 0.93 does not play .mpg files on Mac OS X

[chris clepper]

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
> level
> machine cost $10,000 in 1990!
>

My information comes from sitting at One Infinite Loop with the heads of
QT, Graphics and Imaging, etc during the transition from QT to QTKit.  I
was also there the week all of those people were displaced to make room for
the iPhone team on campus.  It was not a subtle hint where things were
going.
___
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

[chris clepper]

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 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] [ pd-gem-Bugs-3517368 ] gem 0.93 does not play .mpg files on Mac OS X

[chris clepper]

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 we should leave it open for someone to fix rather than removing
> it, but I agree, it is low priority.
>
>
I suggested removing the alea.mpg file (and maybe replace the other
antiquated media files too).

There is no way to remove MPEG-1 support as it's part of Quicktime.
 There's also no way to play an MPEG-1 in an 'alternate' way than just
straight ahead QT calls other than completely changing the code to whatever
half-assed Cocoa replacement Apple is trying to sell this month.  QT used
to be a feature rich API for professional media creation, now it's just
something that plays video on a phone.
___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

Re: [GEM-dev] new libraries on Mac OS X

[Chris Clepper]

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
> 
> 
> 
> ___
> 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

[chris clepper]

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 the only thing holding back the final release of
> Pd-extended 0.43.1.
>
>
> http://sourceforge.net/tracker/?func=detail&aid=3517368&group_id=64325&atid=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

[chris clepper]

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 single line of code that turns it on/off.  GEM's render
engine doesn't do anything different based on that state.


>
> For example, after the all the opengl has been executed, I'm presuming a
> system call is made to actually render the screen? What is this call, and
> could it simply be that something, perhaps operating system related, is
> causing it to take too long to return? That would tie in with moving
> windows around the desktop making the problem worse...
>

The last call in any GL chain is glFinish() which flushes all of the
commands to the card via the driver.  The driver can block the uploading of
commands to the card for various reasons most of which are not documented
anywhere.  Apple has OpenGL profiling tools that can show where time is
being spent in the driver.
___
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

[chris clepper]

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 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] Problem with glitching on OS X at high frame rates

[chris clepper]

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
> 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

[chris clepper]

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 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] USB 2.0 camera and pix_video

[chris clepper]

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 app or the computer.

On Tue, Apr 24, 2012 at 11:34 AM, Florian Grond <
fgr...@techfak.uni-bielefeld.de> wrote:

> Hi List,
>
> I use in my installation a USB 2.0 camera. Most of the time everything
> works as it should however occasionnaly the camera input disappears and I
> see a white texture instead.
> I replug the camera and restart and it works fine
> however if I try to fix it with the patch running
> I get when I try to send the pix_video the message device 6:
> could not make new SG channel error -9405
>
> I send teh message enumerate and I see
> could not get SG channels device list
>
> Any idea if this depends on the camera I use or if there is any way to
> make pix_video "see" the usb camera again after replugging it?
>
>
> Thanks,
>
> Florian
>
>
> __**_
> 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] vertex operations / vertex_* (prev.. gem port to opengl-es - initial developments..)

[chris clepper]

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 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

[chris clepper]

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 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-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)

[chris clepper]

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, 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=detail&aid=3277839&group_id=64325&atid=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

[chris clepper]

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,
> 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)

[chris clepper]

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 wrote:

> 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] [pix_video] osx (fwd)

[chris clepper]

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 wrote:

>
> -- Forwarded message --
> Date: Mon, 14 Feb 2011 08:43:11 -0500 (EST)
> From: Mathieu Bouchard 
> To: IOhannes m zmoelnig 
> 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] AA with shader

[chris clepper]

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 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] FSAA and ATI cards

[chris clepper]

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@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] HD pix_video on Linux

[chris clepper]

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 all,
>
> Are there any options for getting HD (1080p) video input (in Gem) on Linux?
>
> I'm starting a project where SD will not likely cut it, as I'll be doing
> lots of cropping.
>
> I realize it would work out of the box on MacOS, but I'm staying away
> from that.
>
> An HD IP camera may be the way to go, does Gem on Linux load network
> video streams?
>
> Aside: Since HD will be a lot more CPU usage, anyone working on VDPAU
> support in Gem?
>
> Thanks all!
> .b.
>
> ___
> 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] HAVE_CARBONQUICKTIME breaks OSX QT code

[chris clepper]

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 not the compiler!
___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

Re: [GEM-dev] HAVE_CARBONQUICKTIME breaks OSX QT code

[chris clepper]

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 reproduce.
> i checked all the files that make use of "HAVE_CARBONQUICKTIME" and have
> the "undef" keyword, which builds down to Pixes/filmQT.h
> Pixes/recordQT.h, and here HAVE_QUICKTIME get's undefined only if it's
> not w32 and HAVE_CARBONQT is not defined.
> so if HAVE_CARBONQUICKTIME is defined (which it has to be if carbon is
> available) it shouldn't make a difference.
>
>
I defined both and the QT pix_ objects all did nothing when I compiled
them.  I had to change the undefine to define to get it going.  Maybe there
is something else in your setup or a mistake on my part?

The build setup on GEM has always been pretty bad, but now I have no idea
what is what since it has been a long time since I set it up.  The #ifdef
hell has descended several more layers, and I think it is extremely
difficult for even experienced developers to sort it out.
___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

Re: [GEM-dev] HAVE_CARBONQUICKTIME breaks OSX QT code

[chris clepper]

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://gem.iem.at/documentation/faq/how-do-you-compile-gem-on-osx
>
> (i usually don't use xcode, so that's why the project file is not being
> updated accordingly; sorry for that)
>
> if you can post the error, i might be able to fix it.
>
>
ACT-TECH01:src cgc$ autoconf
ACT-TECH01:src cgc$ ./configure
checking for g++... g++
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
./configure: line 2510: syntax error near unexpected token `PIC,'
./configure: line 2510: `GEM_ARG_ENABLE(PIC, PositionIndependentCode
(potentially slower))'
___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

Re: [GEM-dev] HAVE_CARBONQUICKTIME breaks OSX QT code

[chris clepper]

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.

Also, I tried the autoconf on 10.5 and it didn't get very far before dying.


On Tue, Apr 6, 2010 at 8:19 AM, IOhannes m zmoelnig  wrote:

> On 2010-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 pix_film/video/record
> do
> > nothing now.  I guess this is in place in order to build on 10.6?  What
> to
> > do...
>
> define HAVE_CARBONQUICKTIME in the xcode project.
> the autobuilds don't use xcode but autoconf, which will define
> HAVE_CARBONQUICKTIME
>
> and yes: HAVE_CARBONQUICKTIME was introduced for 10.6
>
>
> fgmnasdr
> IOhannes
>
>
___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

[GEM-dev] HAVE_CARBONQUICKTIME breaks OSX QT code

[chris clepper]

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?  What to
do...

Chris
___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

Re: [GEM-dev] pix_crop y coordinates

[chris clepper]

OpenGL is a consortium of manufacturers who have their own agendas and
goals.  The things they agree on make it into the main spec (or ARB), but
they are free to add their own extensions.

If you want the dictatorial model try Microsoft's DX 3D.

On Thu, Mar 18, 2010 at 12:35 PM, Matteo Sisti Sette <
matteosistise...@gmail.com> wrote:

> chris clepper escribió:
>
>
>  OpenGL absolutely allows for platform specific behavior,
>>
>
> Wow, really sad
>
>
>
> --
> Matteo Sisti Sette
> matteosistise...@gmail.com
> http://www.matteosistisette.com
>
___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

Re: [GEM-dev] pix_crop y coordinates

[chris clepper]

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 different results
> (such as an image upside-down in either but not both) something is wrong in
> Gem?
>
>
>
OpenGL absolutely allows for platform specific behavior, and programmers
have to account for those.  This includes writing different shaders for
different platforms!
___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

Re: [GEM-dev] Growing pix_buffer?

[chris clepper]

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 no
penalty.

Chris

On Fri, Mar 12, 2010 at 5:12 PM, B. Bogart  wrote:

> Hey all,
>
> I'm use pix_buffers to store non-sequential images based on index.
>
> I'd like to be able to grow a pix_buffer by 1 element at a time.
>
> [add < would add a single slot to the end of the buffer. Its index would be
> calculated from the length of the buffer.
>
> The object could initiated as a growing pix_buffer by using a 0 as the size
> argument.
>
> There could be an upper limit of how many slots the buffer could grow to.
> Or a second argument could define the max size, but then it would need to
> send a signal when the buffer reached max, so maybe keeping tracking of the
> size on the PD side would work better...
>
> Anyhow I'm just thinking aloud here.
>
> The only alternative I can think of is using a bunch of pix_buffers, each
> holding a single image, that get dynamically created. That is bound to be a
> lot less efficient, and certainly uglier than a central storage area.
>
> .b.
>
> ___
> 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?

[chris clepper]

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 wrote:

>
> 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] ARToolkit issue on 10.4/Intel

[chris clepper]

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 artoolkit support into the 0.92
> build in the current Pd-extended builds?
>
> g++ -o Gem.pd_darwin-dynamiclib -mmacosx-version-min=10.3 -undefined
> dynamic_lookup -framework QuickTime -framework Carbon -framework AGL
> -framework OpenGL   ./Objects/*.o -lAR -L/sw/lib -L/sw/lib -lstdc++ -ldl -lz
> -lm   -lpthread -L/Users/pd/auto-build/pd-extended/pd/bin -L/sw/lib
> -Wl,-framework,OpenGL -Wl,-framework,CoreServices
> -Wl,-framework,ApplicationServices -lobjc -lfreetype -lz -lftgl -L/sw/lib
> -lgmerlin_avdec -lgavl
> ld: common symbols not allowed with MH_DYLIB output format with the
> -multi_module option
> /sw/lib/libAR.a(arUtil.o) definition of common _arParam (size 144)
> /sw/lib/libAR.a(arUtil.o) definition of common _arImXsize (size 16)
> /sw/lib/libAR.a(arUtil.o) definition of common _arImYsize (size 16)
> /sw/lib/libAR.a(arUtil.o) definition of common _arsMatR2L (size 96)
> /sw/lib/libAR.a(arUtil.o) definition of common _arsParam (size 368)
> /usr/libexec/gcc/i686-apple-darwin8/4.0.1/libtool: internal link edit
> command failed
> make[2]: *** [Gem.pd_darwin] Error 1
>
> An Apple person recommends adding -fno-common to the build:
> http://gcc.gnu.org/ml/gcc/2005-06/msg00378.html
>
> Others recommend not using multi_module mode, and sending -single_module:
> http://lists.apple.com/archives/Unix-porting/2006/Aug/msg00024.html
> http://doc.trolltech.com/qt3/platforms/osx.html
>
> .hc
>
>
>
>
>
> 
>
> "[T]he greatest purveyor of violence in the world today [is] my own
> government." - Martin Luther King, Jr.
>
>
>
>
> ___
> 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?

[chris clepper]

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.
>
> 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

[chris clepper]

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 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] gem 64-bit?

[chris clepper]

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 GEM if that happened.


> Then its just window management, which doesn't seem so huge, but I haven't
> done it before.
>

It would require interfacing the C++ code with Objective-C.  It is possible,
but fairly masochistic.


> Am I right in assuming that Gem could really benefit by 64-bit because it
> would allow it to use more than 4 gigs of RAM?
>
>
I cannot recall anyone ever saying they hit this limit.  Even the massive
projects I did using many HD clips and capture never got close to this.

>
>
___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

Re: [GEM-dev] gem 64-bit?

[chris clepper]

There is no 64 bit Carbon support at all.  Apple killed it years ago.

All of the window management and Quicktime code is Carbon.  The rewrite for
Cocoa and 64 bit would be hundreds if not thousands of hours of work.

On Wed, Oct 7, 2009 at 10:13 AM, Hans-Christoph Steiner wrote:

>
> There seems to be some 64-bit support for Carbon, considering the Carbon
> framework is shipped as 64-bit in 10.5.  I know that Carbon is basically
> deprecated, but IIRC, some parts of it are 64-bit. Which parts rely on
> Carbon?
>
> file /System/Library/Frameworks/Carbon.framework/Carbon
> /System/Library/Frameworks/Carbon.framework/Carbon: Mach-O universal binary
> with 4 architectures
> /System/Library/Frameworks/Carbon.framework/Carbon (for architecture
> ppc7400): Mach-O dynamically linked shared library ppc
> /System/Library/Frameworks/Carbon.framework/Carbon (for architecture
> ppc64): Mach-O 64-bit dynamically linked shared library ppc64
> /System/Library/Frameworks/Carbon.framework/Carbon (for architecture i386): 
> Mach-O
> dynamically linked shared library i386
> /System/Library/Frameworks/Carbon.framework/Carbon (for architecture
> 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.
>
> 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
>>>
>>>
>>>
>>> 
>>>
>>> The arc of history bends towards justice. - Dr. Martin Luther King,
>>> Jr.
>>>
>>>
>>>
>>> ___
>>> GEM-dev mailing list
>>> GEM-dev@iem.at
>>> http://lists.puredata.info/listinfo/gem-dev
>>>
>>
>>
>>
>>
>>
>>
>> 
>>
>> All mankind is of one author, and is one volume; when one man dies, one
>> chapter is not torn out of the book, but translated into a better language;
>> and every chapter must be so translated -John Donne
>>
>>
>>
>
>
>
>
>
> 
>
> kill your television
>
>
>
___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

Re: [GEM-dev] gem 64-bit?

[chris clepper]

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
>>
>>
>>
>> 
>>
>> The arc of history bends towards justice. - Dr. Martin Luther King,
>> Jr.
>>
>>
>>
>> ___
>> GEM-dev mailing list
>> GEM-dev@iem.at
>> http://lists.puredata.info/listinfo/gem-dev
>>
>
>
>
>
>
>
> 
>
> All mankind is of one author, and is one volume; when one man dies, one
> chapter is not torn out of the book, but translated into a better language;
> and every chapter must be so translated -John Donne
>
>
>
___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

Re: [GEM-dev] gem 64-bit?

[chris clepper]

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
>
>
>
> 
>
> The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
>
>
>
> ___
> 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

[chris clepper]

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 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

[chris clepper]

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 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

Re: [GEM-dev] problem to play movies at normal speed with GEM objects

[chris clepper]

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 is a single
progressive image per frame.  The JPEG compression is the same, and both use
YUV as the color space.
___
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

[chris clepper]

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 the part opengl
> settings and antialiasing settings but nothing new. I always get
> slowings down on my movies.
> They seem to start during long scenes of the movie (no logic here, i
> know, but it is what i observe).
> Any help ?
> ++
>
> Jack
>
>
> Le lundi 10 août 2009 à 14:43 +0200, Jack a écrit :
> > Le lundi 10 août 2009 à 13:23 +0200, Matteo Sisti Sette a écrit :
> > > Hi,
> > >
> > > Maybe this won't help at all (I only use gem on windows), but just in
> > > case it does:
> > >
> > > Does it work as expected if you disable the "auto" mode and pass the
> > > frame number to the right outlet?
> >
> > I done a counter with a metro and not with gemhead because the framerate
> > pass from 25 to 7 then back to 25, etc. Then it should not change
> > anything compare to [auto 1(.
> > On Linux, the movie is played at each frame render but the rate is not
> > really constant. It was much better on my old Powerbook G4 and MacOSX :)
> > Is there a minipulation to do on the NVidia driver (v. 180.44) ?
> > I know that each frame is render when the buffer is ready with OpenGL
> > (swap buffer in double buffer). But here the swap is very very slow on
> > my brand new Qosmio with a NVidia 9700M GTS ! :)))
> > And this is the same in single buffer mode with :
> >
> > [1 (
> > |
> > [metro 40]
> > |
> > [t b b]
> > | |
> > | to right inlet of pix_film
> > |
> > to gemhead
> >
> >
> > Play a movie with the help patch of [pix_film] at a almost constant rate
> > would not be possible on Linux, i really don't think that it is correct.
> > So, if someone can help me, please ! ;)
> > Thanx a lot.
> > ++
> >
> > Jack
> >
> >
> > PS : some informations from GEM about my config. :
> >
> > GEM information
> > ---
> > OpenGL info
> > Vendor: NVIDIA Corporation
> > Renderer: GeForce 9700M GTS/PCI/SSE2
> > Version: 3.0.0 NVIDIA 180.44
> > Extensions: GL_ARB_color_buffer_float
> > Extensions: GL_ARB_depth_buffer_float
> > Extensions: GL_ARB_depth_texture
> > Extensions: GL_ARB_draw_buffers
> > Extensions: GL_ARB_draw_instanced
> > Extensions: GL_ARB_fragment_program
> > Extensions: GL_ARB_fragment_program_shadow
> > Extensions: GL_ARB_fragment_shader
> > Extensions: GL_ARB_half_float_pixel
> > Extensions: GL_ARB_half_float_vertex
> > Extensions: GL_ARB_framebuffer_object
> > Extensions: GL_ARB_geometry_shader4
> > Extensions: GL_ARB_imaging
> > Extensions: GL_ARB_map_buffer_range
> > Extensions: GL_ARB_multisample
> > Extensions: GL_ARB_multitexture
> > Extensions: GL_ARB_occlusion_query
> > Extensions: GL_ARB_pixel_buffer_object
> > Extensions: GL_ARB_point_parameters
> > Extensions: GL_ARB_point_sprite
> > Extensions: GL_ARB_shadow
> > Extensions: GL_ARB_shader_objects
> > Extensions: GL_ARB_shading_language_100
> > Extensions: GL_ARB_texture_border_clamp
> > Extensions: GL_ARB_texture_buffer_object
> > Extensions: GL_ARB_texture_compression
> > Extensions: GL_ARB_texture_cube_map
> > Extensions: GL_ARB_texture_env_add
> > Extensions: GL_ARB_texture_env_combine
> > Extensions: GL_ARB_texture_env_dot3
> > Extensions: GL_ARB_texture_float
> > Extensions: GL_ARB_texture_mirrored_repeat
> > Extensions: GL_ARB_texture_non_power_of_two
> > Extensions: GL_ARB_texture_rectangle
> > Extensions: GL_ARB_texture_rg
> > Extensions: GL_ARB_transpose_matrix
> > Extensions: GL_ARB_vertex_array_object
> > Extensions: GL_ARB_vertex_buffer_object
> > Extensions: GL_ARB_vertex_program
> > Extensions: GL_ARB_vertex_shader
> > Extensions: GL_ARB_window_pos
> > Extensions: GL_ATI_draw_buffers
> > Extensions: GL_ATI_texture_float
> > Extensions: GL_ATI_texture_mirror_once
> > Extensions: GL_S3_s3tc
> > Extensions: GL_EXT_texture_env_add
> > Extensions: GL_EXT_abgr
> > Extensions: GL_EXT_bgra
> > Extensions: GL_EXT_blend_color
> > Extensions: GL_EXT_blend_equation_separate
> > Extensions: GL_EXT_blend_func_separate
> > Extensions: GL_EXT_blend_minmax
> > Extensions: GL_EXT_blend_subtract
> > Extensions: GL_EXT_compiled_vertex_array
> > Extensions: GL_EXT_Cg_shader
> > Extensions: GL_EXT_bindable_uniform
> > Extensions: GL_EXT_depth_bounds_test
> > Extensions: GL_EXT_direct_state_access
> > Extensions: GL_EXT_draw_buffers2
> > Extensions: GL_EXT_draw_instanced
> > Extensions: GL_EXT_draw_range_elements
> > Extensions: GL_EXT_fog_coord
> > Extensions: GL_EXT_framebuffer_blit
> > Extensions: GL_EXT_framebuffer_multisample
> > Extensions: GL_EXT_framebuffer_object
> > Extensions: GL_EXTX_framebuffer_mixed_formats
> > Extensions: GL_EXT_framebuffer_sRGB
> > Extensions: GL_EXT_geometry_shader4
> > Extensions: GL_EXT_gpu_program_parameters
> > Extensions: GL_EXT_gpu_shader4
> > Extensions: GL_EXT_multi_draw_arrays
> > Extensions: GL_EXT_packed_dep

Re: [GEM-dev] Problem with textures on Ubuntu

[chris clepper]

You are just going to have to test it.  On OSX video textures that are
multiples of 16 have been twice as efficient or more.

On Thu, Jun 25, 2009 at 11:10 AM, Jack  wrote:

> Hello Chris,
> Excuse me to come back on this question. But can you help me about width
> image size and drivers ? Do you know if there is optimization with the
> NVidia driver 180.44 and images with size multiple of 16 px in width ? If
> the answer is yes, i have to resize my images because i use 768 textures
> with different size at 4 fps (enough for me but if i can optimize, why not
> ;). (I use GeForce 9700M GTS on Ubuntu 9.04).
> Thanx.
> ++
>
> Jack
>
>
> Le 24 juin 09 à 16:55, Jack a écrit :
>
> Thanx Chris, but the solution given by Iohannes seems to work 
> perfectly.However,
> is it better for performance to give to an image a width multiple of
> 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 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 127x108 and 72x123 pixels (so the total
>> size at 24bit is near 12 MB ! : 127x108x3x300/1048576 = 11.77 MB).
>>
>
> Most of the drivers have optimizations for images that are a multiple of 16
> in width, so maybe try using 128 pixel wide images and see if that helps.
>
>
> ___
> 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 textures on Ubuntu

[chris clepper]

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 127x108 and 72x123 pixels (so the total
> size at 24bit is near 12 MB ! : 127x108x3x300/1048576 = 11.77 MB).
>

Most of the drivers have optimizations for images that are a multiple of 16
in width, so maybe try using 128 pixel wide images and see if that helps.
___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

Re: [GEM-dev] error: invalid conversion from 'GLint*' to 'long int*'

[chris clepper]

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=32 -funroll-loops
> -ffast-math -mmmx -fpascal-strings  -I/sw/include   -I/sw/include/freetype2
> -I..  -I/usr/include/FTGL -I/usr/include/freetype2
> -I/Users/pd/auto-build/pd-extended/pd/src  GemPBuffer.cpp -o
> ../Objects/GemPBuffer.o
> GemPBuffer.cpp: In constructor 'PBuffer::PBuffer(int, int, int)':
> GemPBuffer.cpp:270: error: invalid conversion from 'GLint*' to 'long int*'
> GemPBuffer.cpp:270: error:   initializing argument 2 of 'CGLError
> CGLGetVirtualScreen(_CGLContextObject*, long int*)'
> GemPBuffer.cpp:272: error: invalid conversion from 'GLint*' to 'long int*'
> GemPBuffer.cpp:272: error:   initializing argument 3 of 'CGLError
> CGLChoosePixelFormat(const CGLPixelFormatAttribute*,
> _CGLPixelFormatObject**, long int*)'
> GemPBuffer.cpp:283: error: invalid conversion from 'GLint*' to 'long int*'
> GemPBuffer.cpp:283: error:   initializing argument 2 of 'CGLError
> CGLGetVirtualScreen(_CGLContextObject*, long int*)'
> GemPBuffer.cpp: In member function 'void PBuffer::enable()':
> GemPBuffer.cpp:307: error: invalid conversion from 'GLint*' to 'long int*'
> GemPBuffer.cpp:307: error:   initializing argument 2 of 'CGLError
> CGLGetVirtualScreen(_CGLContextObject*, long int*)'
> make[3]: *** [GemPBuffer.o] Error 1
> make[2]: *** [Base] Error 2
> make[1]: *** [/Users/pd/auto-build/pd-extended/Gem/src/Gem.pd_darwin] Error
> 2
> make: *** [extended_install] Error 2
>
>
>
>
> 
>
> All mankind is of one author, and is one volume; when one man dies, one
> chapter is not torn out of the book, but translated into a better language;
> and every chapter must be so translated -John Donne
>
>
>
> ___
> 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 / firewire / osX

[chris clepper]

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 Graffagnino
and tell him to get his group's shit together.

On Wed, May 27, 2009 at 5:59 PM, cyrille henry
wrote:

> hello,
> i'm curently working for a company using osX, so i'm glue on a macbook pro.
>
> i experienced a bug describe on this list in nevember 2008 : pix_video grab
> only a small portion of the image of a DV cam. i'm wondering if somthing new
> has append since then. (no real solution was found, sending a dim message to
> pix_video did not help)
> is there something i can make to have pix_video to grab the whole image?
> sending the dialog message to pix_video open a configuration windows where
> the whole image is display...
>
> i'm using an old pd extended version, i'm wondering if updating it would
> help : is there some new stuff?
>
> thanks
> Cyrille
>
>
>
>
> ___
> 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_multiimage .png problem 2nd

[chris clepper]

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 need a sequence with an
> alpha channel so combining the stillframes to a video is no option
> what i'd really need is a loader that constantly loads and unloads
> the sequences from the memory when ever they are needed
> but presentation is on monday so i might leave it at the current
> state.
>
> thx
> johann
>
>
>
> ___
> 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_multiimage .png problem 2nd

[chris clepper]

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.  The movie will not decompress, so
the savings of PNG or another codec will work there.  This works on OSX and
Windows.

On Tue, May 19, 2009 at 7:29 PM, johann scholz  wrote:

> hi again,
>
> very special thx to jack!! your tip with the lzw saving broke
> the size of the sequences more than in half..
> BUT!!!
> it still crashes pd when i try to add another sequence, don't know why?
> i now have 11 sequences(about 485 mb) preloaded but want to use up to
> 20 sequences(about 900 mb)...funny thing is when i look at the task
> manager when the patch is open it uses more than 2gb of my memory
> already and of my virtual memory, even whith the 11 sequences..don't
> understand
> it, might be a prob at the preloader...speaking in terms it's loading it to
> often? even
> though in the pd output it loads it just one time...i just don't get it!
>
> i attached the patch(+ 2 subpatches---videoset is the preloader), but not
> the sequences beacause they are obviously to big, to this email,
> perhaps someone finds an optimization!!!
>
> thx again
> johann
>
> ps: the .png didn't work so i stick to the .tif format
>
> pd version: pd extended 0.40.3
> os: winxp
>
> ___
> 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] it it possible to use GPU accelerated h.264 decoding on OS X?

[chris clepper]

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 you say, it would probably be still impossible to play
> 1080p with [pix_film] without hw accel.
>

I made many GEM based art works that played 4 1080 clips and recorded a live
stream to disk all in real time.  I think the problem you are having is the
H.264 codec, which is intended for ultra-low data bandwidth applications.
 Switching to Apple Intermediate or one of the professional codecs
(DVCPRO_HD or ProRes) will improve performance far more than trying to
offload the 100:1 compressed H.264 to the GPU.
___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

Re: [GEM-dev] it it possible to use GPU accelerated h.264 decoding on OS X?

[chris clepper]

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
again.  Apple has some new optimized ways to play video, but they are far
too limited for use in GEM.

On Tue, May 12, 2009 at 2:52 PM, Roman Haefeli  wrote:

> hi all
>
> somehow related to frank's question, but i would like to achieve the
> opposite: _more_ hw acceleration (instead of less).
>
> i found, that on new macs, playing even full-hd h.264 quicktime files
> doesn't eat any noticable cpu processing. on a macbook pro unibody, it
> takes around 13% (says 'activity monitor') playing it with quicktime
> 7.X.X.  the same movie played by [pix_film] from Gem from
> pd-extended-0.40.3 takes ~60% (of one core). if it is correct to
> believe, that gem makes use of the quicktime API on os x, is there a way
> to make it use of the gpu accelerated h.264 decoding feature?
>
> hm.. i should have checked, whether the plain decoding uses much cpu or
> if probably some significant chunk is used for displaying. i'll test
> tomorrow, when i have access to a mac again.
>
> any hints about the topic are welcome.
>
> roman
>
>
>
>
> ___
> Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
>
>
> ___
> 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] help files gemgl*

[chris clepper]

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 Mon, Mar 23, 2009 at 6:20 PM, Hans-Christoph Steiner wrote:

>
> I am just looking at some of the GEMgl stuff, and noticed there are no
> helpfiles for any of them.  It seems that it would be quite useful to make a
> help template for these functions, then generate them automatically, since
> the objects themselves were auto-generated.  It would be very nice to have
> these help patches already generated from the OpenGL reference, and also
> included a link, perhaps.
>
> I just committed GLdefine-help.pd as a start.  Any thoughts on that?
>
> .hc
>
>
> 
>
> As we enjoy great advantages from inventions of others, we should be glad
> of an opportunity to serve others by any invention of ours; and this we
> should do freely and generously. - Benjamin Franklin
>
>
>
> ___
> 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 grabs with wrong resolution (again)

[chris clepper]

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/003729.html
>
> I have the same behavior> pix_video displays only a portion of the
> image, like it was zoomed in. The difference from what Max had back
> then is that I am using a Fire-i camera with IOXperts driver.
>
> If I send a dialog message to pix_video I see two different cameras
> (only one is actually connected though): "Unibrain FIre-i" and
> "mycamera". They are the same camera, "mycamera" is just the name
> given when registering the "Unibrain Fire-i" with IOXperts. When the
> dialog box appears "mycamera" is selected and the preview is only the
> top left fraction of the image. I then click on "Unibrain Fire-i" and
> the images gets fixed: the whole frame is displayed. I then choose
> "mycamera" and is fixed aswell. I can then work normally.
>
> I need to setup an installation that needs to automatically turn on
> everyday and just work, so this manual setting is unacceptable. I
> suppose that if I send a device message to pix_video to select
> "Unibrain Fire-i" and then another selecting "mycamera" from within
> the pd patch, a similar behavior would ensure and the problem would be
> fixed. how do device messages in osx work? I get this in pd console
> with pix_video:
>
> [pix_videoDarwin]: pix_videoDarwin: SG channnel Device List count 8 index 6
> [pix_videoDarwin]: pix_videoDarwin: SG channnel Device List   DV Video
> [pix_videoDarwin]: pix_videoDarwin: SG channnel Device List   DVCPRO
> HD (1080i50)
> [pix_videoDarwin]: pix_videoDarwin: SG channnel Device List   DVCPRO
> HD (1080i60)
> [pix_videoDarwin]: pix_videoDarwin: SG channnel Device List   DVCPRO
> HD (720p25/50)
> [pix_videoDarwin]: pix_videoDarwin: SG channnel Device List   DVCPRO
> HD (720p60)
> [pix_videoDarwin]: pix_videoDarwin: SG channnel Device List   IIDC
> FireWire Video
> [pix_videoDarwin]: pix_videoDarwin: SG channnel Device List   mycamera
> [pix_videoDarwin]: pix_videoDarwin: SG channnel Device List   USB
> Video Class Video
> [pix_videoDarwin]: pix_videoDarwin: SGSetChannelDevice trying  DVCPRO
> HD (720p60)
> [pix_videoDarwin]: pix_videoDarwin: SGSetChannelDevice returned error 704
> [pix_videoDarwin]: pix_videoDarwin : vdigName is  r2
>
> I tried using
>
>  [device 0, input 0, dimen 640 480( as suggested here
> http://www.mail-archive.com/pd-l...@iem.at/msg15811.htmlusing
> different device numbers but had no success.
>
> any help would be appreciated. I do not know what else to do.
>
> Thankyou all.
>
> ___
> 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