Re: [PD] pix_record mixed pixes
vincent Rioux a écrit : thanks IOhannes for being patient. well, i am still a bit unsure. do you mean that the stuff i described below canNOT be recorded at all within puredata? i.e. do i have to make a recording using the ouput of the graphic card? i am now trying to record a single rectangle moving over the Gem window. do i have to use pix_snap synchronized with pix_record to take a sequence of snapshots? (i only get a green video output). vincent IOhannes m zmoelnig a écrit : vincent Rioux wrote: i am not sure whether i fully understand what you mean. i agree with you, my description is not crystal clear. imagine that there is a video in the background (fullscreen). progressively some small recatngular parts of the video are transformed (for example gets darker) and move - in order to do that i apply another gem layer on top of the video layer and insert several rectangles objects with alpha channel. thanks. what you describe canNOT be recorded directly with [pix_record] (you already know that). [pix_record] will _only_ record pixes. (e.g. you have to transform your rectangles into pix-domain; just using [rectangle] won't do) ok, how do one make this kind of transformation? [pix_snap] transforms the rendering buffer (what has been rendered so far in the render-cycle!) into a pix-buffer. e.g. [pix_video] | [pix_gain] | [pix_record] | [pix_invert] will record a video with [pix_gain] applied, but [pix_invert] is NOT applied. ok, i think i got this one but what about pix_mix? [pix_mix] is harder to draw in ascii. apart from that you shoud insert it instead of [pix_gain] to have an effect. mfg.adsr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list It would be nice if pix_snap worked on winslows ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_record mixed pixes
On 12/11/06, Patco [EMAIL PROTECTED] wrote: It would be nice if pix_snap worked on winslows The example patch 07.Snapshot1.pd works on Windows here. What problem do you have? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_record mixed pixes
chris clepper a écrit : Very simple example of pix_snap and pix_record attached. The example patch 07.Snapshot1.pd works on Windows here. What problem do you have? The attached exemple makes a movie with a black screen, instead of the nice rotating lined cube. *snip* GEM: ver: 0.91-cvs GEM: compiled: Sep 8 2006 GemMan: create window GLEW version 1.3.3 GEM: Start rendering GL: énumérant non valide recordQT : filename C:/img/test.mov pix_record: recording on! recordQT: setup end recordQT : movie written to C:/img/test.movÍÍÍ pix_record : movie written *snip* In the 07.Snapshot1.pd example, pd crashes when I click on [snap(, using pd-0.40-1, I've tried with the last nightly build, it crashed when I render gemwin. ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_record mixed pixes
On 12/11/06, vincent Rioux [EMAIL PROTECTED] wrote: thanks IOhannes for being patient. well, i am still a bit unsure. do you mean that the stuff i described below canNOT be recorded at all within puredata? i.e. do i have to make a recording using the ouput of the graphic card? i am now trying to record a single rectangle moving over the Gem window. do i have to use pix_snap synchronized with pix_record to take a sequence of snapshots? (i only get a green video output). Yes, you need pix_snap to get the contents of the gemwin. You may need to send a 'colorspace RGBA' message to pix_record on OSX. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
RE: [PD] pix_record mixed pixes
On Thu, 7 Dec 2006, Danks, Mark wrote: Actually, this one is more complicated, because it involves the underlying pix buffer. That has nothing to do with OpenGL... Isn't the situation of the pixes exactly the same as the one of OpenGL ? That is, that it's all really one big global variable... why do gem messages exist? They could be bangs and it would give the same result. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_record mixed pixes
On 12/8/06, Mathieu Bouchard [EMAIL PROTECTED] wrote: :How do i get [separator] to separate colours? I was teaching the use of [separator] in a workshop and then I realised that it doesn't backup colours. Is [separator] really only for transformation matrices or is there an option to enable it to work with [colorRGB] and [alpha] and etc? Just the transformation matrices. The color objects overwrite the current color. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_record mixed pixes
On Fri, 8 Dec 2006, chris clepper wrote: On 12/8/06, Mathieu Bouchard [EMAIL PROTECTED] wrote: :How do i get [separator] to separate colours? I was teaching the use of [separator] in a workshop and then I realised that it doesn't backup colours. Is [separator] really only for transformation matrices or is there an option to enable it to work with [colorRGB] and [alpha] and etc? Just the transformation matrices. The color objects overwrite the current color. (and that's a feature?) Is there a different class that can separate colours instead of just pixes and coordinate-systems ? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_record mixed pixes
On 12/8/06, Mathieu Bouchard [EMAIL PROTECTED] wrote: On Fri, 8 Dec 2006, chris clepper wrote: On 12/8/06, Mathieu Bouchard [EMAIL PROTECTED] wrote: :How do i get [separator] to separate colours? I was teaching the use of [separator] in a workshop and then I realised that it doesn't backup colours. Is [separator] really only for transformation matrices or is there an option to enable it to work with [colorRGB] and [alpha] and etc? Just the transformation matrices. The color objects overwrite the current color. (and that's a feature?) The spec on glColor: http://www.rush3d.com/reference/opengl-bluebook-1.0/ch05.html#id5458953 Is there a different class that can separate colours instead of just pixes and coordinate-systems ? Every vertex can have a color assigned to it. In GEM the same color is applied to every vertex in a Geo because the interface to do otherwise would be cumbersome. You can set the color once and then every vertex in as many Geo objects as you put after [color] will be that color. It is highly recommended to place a color object before each Geo. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_record mixed pixes
On Wed, 6 Dec 2006, IOhannes m zmoelnig wrote: due to the signal-flow nature of pix-processing you have to add [pix_record] after all pix-processing objects you want to have an effect on the recorded video. that's not very surprising: the same thing would happen to messages and DSP. (well, I'm surprised by the phrase signal flow: what does it mean?) what's a lot more surprising is that [pix_video] | [pix_gain] | [t a a] | | | [pix_invert] | [pix_record] actually applies [pix_invert], because gem messages handle pix (and all the other state) by pointer, so that the pix seemingly sent from [pix_gain] to [pix_record] is actually modified although the message sent isn't modified. This doesn't necessarily happen in other video plugins. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_record mixed pixes
On 12/7/06, Mathieu Bouchard [EMAIL PROTECTED] wrote: what's a lot more surprising is that [pix_video] | [pix_gain] | [t a a] | | | [pix_invert] | [pix_record] actually applies [pix_invert], because gem messages handle pix (and all the other state) by pointer, so that the pix seemingly sent from [pix_gain] to [pix_record] is actually modified although the message sent isn't modified. This doesn't necessarily happen in other video plugins. Reversing the order of pix_invert and pix_record won't apply the inversion though. That would be consistent with the rest of Pd messaging right? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
RE: [PD] pix_record mixed pixes
Keep in mind that GEM builds a graph based on the pointers when you turn on rendering. Pix_invert and pix_record are both using that same pointer, and the [t] object is simply controlling the order of the graph that is constructed. In fact, when rendering, the [t] object doesn't get any messages at all...all messages/events are happening in that constructed graph. This basically the same as how the ~ objects work. Reversing the order pix_invert and pix_record will still apply the invert...it will just happen after the pix_record happens. Mark From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of chris clepper Sent: Thursday, December 07, 2006 10:07 AM To: Mathieu Bouchard Cc: pd-liste; vincent Rioux; IOhannes m zmoelnig Subject: Re: [PD] pix_record mixed pixes On 12/7/06, Mathieu Bouchard [EMAIL PROTECTED] wrote: what's a lot more surprising is that [pix_video] | [pix_gain] | [t a a] | | | [pix_invert] | [pix_record] actually applies [pix_invert], because gem messages handle pix (and all the other state) by pointer, so that the pix seemingly sent from [pix_gain] to [pix_record] is actually modified although the message sent isn't modified. This doesn't necessarily happen in other video plugins. Reversing the order of pix_invert and pix_record won't apply the inversion though. That would be consistent with the rest of Pd messaging right? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_record mixed pixes
On 12/7/06, Danks, Mark [EMAIL PROTECTED] wrote: Reversing the order pix_invert and pix_record will still apply the invert…it will just happen after the pix_record happens. That is a much clearer way to say what I was try to say. The inversion will not be applied to the image input to pix_record, but the processing would still happen. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_record mixed pixes
On Thu, Dec 07, 2006 at 01:00:04PM -0600, chris clepper wrote: On 12/7/06, Danks, Mark [EMAIL PROTECTED] wrote: Reversing the order pix_invert and pix_record will still apply the invert?it will just happen after the pix_record happens. That is a much clearer way to say what I was try to say. The inversion will not be applied to the image input to pix_record, but the processing would still happen. Well, I don't want to speak for Matju, but I think what he's saying is that he realises this, but it is counter intuitive and suprising. If I have a dsp or message graph and I send the output of something through some modifiers, I don't expect those modifiers to be automatically applied to another cable going somewhere else. I expect modifiers further down the tree to only effect things on the same branch. Essentially, when patching Gem, you have to be even more aware of the order of operations than when just regularly patching dsp, because operations on one branch of the graph can affect operations on another branch of the graph. I guess one way to 'fix' that (and break backwards compatability) would be perform a GLPushMatrix every time there is a fork in the graph, and a GLPopMatrix every time you get to a leaf node. Best, Chris. --- [EMAIL PROTECTED] http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
RE: [PD] pix_record mixed pixes
Actually, this one is more complicated, because it involves the underlying pix buffer. That has nothing to do with OpenGL... Mark -Original Message- From: Chris McCormick [mailto:[EMAIL PROTECTED] Sent: Thursday, December 07, 2006 7:49 PM To: chris clepper Cc: Danks, Mark; Mathieu Bouchard; pd-liste; vincent Rioux; IOhannes m zmoelnig Subject: Re: [PD] pix_record mixed pixes On Thu, Dec 07, 2006 at 01:00:04PM -0600, chris clepper wrote: On 12/7/06, Danks, Mark [EMAIL PROTECTED] wrote: Reversing the order pix_invert and pix_record will still apply the invert?it will just happen after the pix_record happens. That is a much clearer way to say what I was try to say. The inversion will not be applied to the image input to pix_record, but the processing would still happen. Well, I don't want to speak for Matju, but I think what he's saying is that he realises this, but it is counter intuitive and suprising. If I have a dsp or message graph and I send the output of something through some modifiers, I don't expect those modifiers to be automatically applied to another cable going somewhere else. I expect modifiers further down the tree to only effect things on the same branch. Essentially, when patching Gem, you have to be even more aware of the order of operations than when just regularly patching dsp, because operations on one branch of the graph can affect operations on another branch of the graph. I guess one way to 'fix' that (and break backwards compatability) would be perform a GLPushMatrix every time there is a fork in the graph, and a GLPopMatrix every time you get to a leaf node. Best, Chris. --- [EMAIL PROTECTED] http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_record mixed pixes
On 12/7/06, Chris McCormick [EMAIL PROTECTED] wrote: I guess one way to 'fix' that (and break backwards compatability) would be perform a GLPushMatrix every time there is a fork in the graph, and a GLPopMatrix every time you get to a leaf node. That's just doing the same thing as the [separator]/[pix_separator] objects. I think effort would be better spent making more documentation which clearly shows how patching differs from DSP and message objects. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_record mixed pixes
vincent Rioux wrote: dear list, I recently tried out pix_record object of Gem, running pd-39.2-extended for osx. It worked pretty fine but i could not record anything else than a video connected to a unique gemhead. i tried to mix several pixes (like moving rectangles with alpha layer) with the video using pix_mix but when recording the visual output i only get the video (without the applied 'transformations'). is that an expected behaviour? i am not sure whether i fully understand what you mean. [pix_record] will _only_ record pixes. (e.g. you have to transform your rectangles into pix-domain; just using [rectangle] won't do) due to the signal-flow nature of pix-processing you have to add [pix_record] after all pix-processing objects you want to have an effect on the recorded video. e.g. [pix_video] | [pix_gain] | [pix_record] | [pix_invert] will record a video with [pix_gain] applied, but [pix_invert] is NOT applied. mfga-dr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_record mixed pixes
On 12/6/06, Kyle Klipowicz [EMAIL PROTECTED] wrote: I've never explored this object, but it sounds great! There's a way to capture openGL to pix objects right? So pix_record could be used to record an entire GEM session to a video file? Put pix_snap in front of pix_record. Don't expect a high framerate capture for large gemwins though. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
