hi list
i have an intel mac and tried to install the nightly build
(Pd-0-1.39.2-extended-2006-12-05-macosx104-i386.dmg)
whenever i start the app it doesn't run. I only see its icon jumping
once or twice in the dock
has it occurred to anyone? how can I solve it?
thks
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?
best, vincent
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
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?
~Kyle
On 12/6/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
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
On 12/6/06, Kyle Klipowicz kyleklip@gmail.com 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.
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
On 12/7/06, Mathieu Bouchard matju@artengine.ca 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?
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: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] 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 matju@artengine.ca 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?
On 12/7/06, Danks, Mark MDanks@ea.com 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.
On Thu, Dec 07, 2006 at 01:00:04PM -0600, chris clepper wrote:
On 12/7/06, Danks, Mark MDanks@ea.com 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.
chris@mccormick.cx http://mccormick.cx
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:chris@mccormick.cx] 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 MDanks@ea.com 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.
chris@mccormick.cx http://mccormick.cx
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
Couple of reasons for that...
I didn't want to have to hook up a metro to everything which wanted to render...and then manage all of those connections. You don't have to do that with the ~ objects so why should you have to do that with GEM? Since I still needed the network connectivity, I used the render 1 message to trigger all of the gemheads to generate the graph behind the scenes.
With the pixes, it was because I did a lot of buffer storage and manipulation so that I didn't waste memory or unneeded processing time. This is the reason for all of the dirty flags, etc. I probably would do it differently today, but back when an SGI Indy was top of the line it was a different story :-)
Mark
-----Original Message----- From: Mathieu Bouchard [mailto:matju@artengine.ca] Sent: Friday, December 08, 2006 6:40 PM To: Danks, Mark Cc: Chris McCormick; chris clepper; pd-liste; vincent Rioux; IOhannes m zmoelnig Subject: 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
On 12/7/06, Chris McCormick chris@mccormick.cx 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.
On Thu, 7 Dec 2006, chris clepper wrote:
On 12/7/06, Chris McCormick chris@mccormick.cx 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.
Hey, this reminds me of a question I asked on gem-dev in October and got no reply. Here it is again:
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?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On 12/8/06, Mathieu Bouchard matju@artengine.ca 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.
On Fri, 8 Dec 2006, chris clepper wrote:
On 12/8/06, Mathieu Bouchard matju@artengine.ca 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
On 12/8/06, Mathieu Bouchard matju@artengine.ca wrote:
On Fri, 8 Dec 2006, chris clepper wrote:
On 12/8/06, Mathieu Bouchard matju@artengine.ca 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.
On Fri, 8 Dec 2006, Chris McCormick wrote:
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. [...]
That's exactly what I meant. Thank you.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
IOhannes m zmoelnig a écrit :
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.
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.
[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?
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.
ok, i think i got this one but what about pix_mix?
cordially, vincent
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
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
On 12/11/06, vincent Rioux vincent.rioux@no-log.org 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.
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
On 12/11/06, Patco megalegoland@yahoo.fr 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?
Very simple example of pix_snap and pix_record attached.
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
That one is broken, try 2006-12-06
.hc
On Dec 6, 2006, at 6:34 AM, Miguel Cardoso wrote:
hi list
i have an intel mac and tried to install the nightly build
(Pd-0-1.39.2-extended-2006-12-05-macosx104-i386.dmg) whenever i start the app it doesn't run. I only see its icon
jumping once or twice in the dockhas it occurred to anyone? how can I solve it?
thks _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
-
chris clepper -
Chris McCormick -
Danks, Mark -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Kyle Klipowicz -
Mathieu Bouchard -
Miguel Cardoso -
Patco -
vincent Rioux