hi gemmers,
just talking with jamie here in bergen and it's pretty clear to me how to write the bridge between libpdp and Gem.
practicly, for me it is the build system. i'd like to add 5 objects. 3 of them are already in the pf/pd bridge.
* [gem.get <thing>] : forks off one gemstate object as pdp packet * [gem.set <thing>] : inserts one pdp object in gem state * [pdp <thing>] : generic pdp processors (functional maps) * [3dp <thing] : 3d drawing objects (draw to current gl context) * [pf <script>] : any pf script
the last 3 i have C code for and they don't depend on gem, but if pf/pdp/3dp is running inside Gem they need to be included.
the first 2 need to be written from scratch as gem objects, possibly just derived from GemBase.
i suggest someone helps me with setting this up, by adding templates for the gem.get and gem.set objects in the source tree and add them to the build process. the names are of course open to discussion. anything sane and short.
the rest i need is just an init callback. this callback will: * initialize the forth and pdp memory manager * create the pf/pdp/3dp pd objects
maybe it is best to keep this optional, since it introduces a library dependency.
so, who is motivated to help me out here by adding the templates? i don't have time to learn the build and init process.
cheers tom
Tom Schouten wrote:
hi gemmers,
so, who is motivated to help me out here by adding the templates? i don't have time to learn the build and init process.
shouldn't be too much of a hazzle, so (i guess) i volunteer..
- [gem.get <thing>] : forks off one gemstate object as pdp packet
- [gem.set <thing>] : inserts one pdp object in gem state
the names are of course open to discussion. anything sane and short.
i'd rather have "pdp" somewhere in the name, as [gem.set] and [gem.get] could be anything (not necessarily related to pure data packets)
for me the most simple names i can think of right now are [gem_pdp] : gem->pdp (or probably [gem_3dp] ?) [pdp_gem] : pdp->gem
the first 2 need to be written from scratch as gem objects, possibly just derived from GemBase.
i suggest someone helps me with setting this up, by adding templates for the gem.get and gem.set objects in the source tree and add them to the build process.
so what exactly should these do (aka: what do you want me to make them do) ?
how would a patch look like ?
<snip> [gemhead] | [gem.get] | [pdp_noise] | [gem.set] | [pix_texture] | [square] </snip>
and the pdp packet would just hold (additionally) the data of the gem_list (?)
and i guess, that [gem.get] should *not* output the gem_list anymore ?
sorry for being not into pdp-code ;-)
mfg.asd.r IOhannes
Johannes M Zmoelnig wrote:
Tom Schouten wrote:
- [gem.get <thing>] : forks off one gemstate object as pdp packet
- [gem.set <thing>] : inserts one pdp object in gem state
on re-reading this appears to me rather like:
<snip> [gemhead] | [gem.set noise] | [pix_texture] | [square] </snip>
than
<snip> [gemhead] | [gem.get] | [pdp_noise] | [gem.set] | [pix_texture] | [square] </snip>
is this correct ?
how would you use [gem.get] then ?
questions, questions,....
mfg.as.dr IOhannes
so, who is motivated to help me out here by adding the templates? i don't have time to learn the build and init process.
shouldn't be too much of a hazzle, so (i guess) i volunteer..
thanks johannes!
- [gem.get <thing>] : forks off one gemstate object as pdp packet
- [gem.set <thing>] : inserts one pdp object in gem state
the names are of course open to discussion. anything sane and short.
i'd rather have "pdp" somewhere in the name, as [gem.set] and [gem.get] could be anything (not necessarily related to pure data packets)
for me the most simple names i can think of right now are [gem_pdp] : gem->pdp (or probably [gem_3dp] ?) [pdp_gem] : pdp->gem
since it's really only 'get' and 'set' (just about exchainging data with a gem render chain) i think this should be clear in the name.
the object qualify as 'gem chain objects' not pdp objects. so [pdp_xxx] seems confusing.
the first 2 need to be written from scratch as gem objects, possibly just derived from GemBase.
i suggest someone helps me with setting this up, by adding templates for the gem.get and gem.set objects in the source tree and add them to the build process.
so what exactly should these do (aka: what do you want me to make them do) ?
how would a patch look like ?
<snip> [gemhead] | [gem.get] | [pdp_noise] | [gem.set] | [pix_texture] | [square] </snip>
a getter would look like:
[gemhead] | [gem.get pixbuf] | | | [pdp_gain 2.0] | | | [pdp_blur] | | [gem.set pixbuf] | [pix_texture] | [square]
this would fork off the pixbuf as a pdp packet, then process it using pdp_gain and pdp_blur, and insert it back into gemstate.
and the pdp packet would just hold (additionally) the data of the gem_list (?)
and i guess, that [gem.get] should *not* output the gem_list anymore ?
i think it should, because the get/set objects are really renderchain objects.
Tom Schouten wrote:
i'd rather have "pdp" somewhere in the name, as [gem.set] and [gem.get] could be anything (not necessarily related to pure data packets)
for me the most simple names i can think of right now are [gem_pdp] : gem->pdp (or probably [gem_3dp] ?) [pdp_gem] : pdp->gem
since it's really only 'get' and 'set' (just about exchainging data with a gem render chain) i think this should be clear in the name.
the object qualify as 'gem chain objects' not pdp objects. so [pdp_xxx] seems confusing.
true. still i think that "pdp" should be in the name too, as [gem_set] wouldn't necessarily have something to do with pdp packages. so probably [gem_pdpout} and [gem_pdpin] would be more apropriate ? (or [gem_pdp.out] and [gem_pdp.in])
a getter would look like:
[gemhead] | [gem.get pixbuf] | | | [pdp_gain 2.0] | | | [pdp_blur] | | [gem.set pixbuf] | [pix_texture] | [square]
this would fork off the pixbuf as a pdp packet, then process it using pdp_gain and pdp_blur, and insert it back into gemstate.
thanks for the clarification
and the pdp packet would just hold (additionally) the data of the gem_list (?)
and i guess, that [gem.get] should *not* output the gem_list anymore ?
i think it should, because the get/set objects are really renderchain objects.
which is clear from your sketch.
so the templates are almost done; just want to settle the name before i check them in
mfg.a.sdr IOhannes
since it's really only 'get' and 'set' (just about exchainging data with a gem render chain) i think this should be clear in the name.
the object qualify as 'gem chain objects' not pdp objects. so [pdp_xxx] seems confusing.
true. still i think that "pdp" should be in the name too, as [gem_set] wouldn't necessarily have something to do with pdp packages. so probably [gem_pdpout} and [gem_pdpin] would be more apropriate ? (or [gem_pdp.out] and [gem_pdp.in])
...
so the templates are almost done; just want to settle the name before i check them in
[gem_pdp.out] and [gem_pdp.in] seem ok to me
or even
[out_pdp] and [in_pdp] to keep them shorter, since most gem objects don't have a gem_ prefix.
yeah, politics!
to match the convension of gem
pdp_in and pdp_out would be best
(since we have sub-chains with prefixes in gem, pix_ vertex_ etc.. )
B.
(I'm looking forward to play with this...)
since it's really only 'get' and 'set' (just about exchainging data with a gem render chain) i think this should be clear in the name.
the object qualify as 'gem chain objects' not pdp objects. so [pdp_xxx] seems confusing.
true. still i think that "pdp" should be in the name too, as [gem_set] wouldn't necessarily have something to do with pdp packages. so probably [gem_pdpout} and [gem_pdpin] would be more apropriate ? (or [gem_pdp.out] and [gem_pdp.in])
...
so the templates are almost done; just want to settle the name before i check them in
[gem_pdp.out] and [gem_pdp.in] seem ok to me
or even
[out_pdp] and [in_pdp] to keep them shorter, since most gem objects don't have a gem_ prefix.
yeah, politics!
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
B. Bogart wrote:
to match the convension of gem
pdp_in and pdp_out would be best
(since we have sub-chains with prefixes in gem, pix_ vertex_ etc.. )
well, but the pdp_ prefix is for pdp-objects (not for gem objects) ther will only be 2 such objects, so i don't think it is worth to start a new "class", otoh the "gem_" prefix would indicate that something "serious" is going on ;-)
anyhow, i have added the files now to the HEAD into src/Control/
the files are called gem_pdpout.{cpp|h}, resp. gem_pdpin.{cpp|h} [gem_pdp.out] and [gem_pdp.in] are aliases (easier for me)
to add the files to your build-system, just re-run the "makesource"-script in Gnu and recompile. allons-nous!!
mfg.mi.dxy IOhannes
...now that IOhannes has committed something, I may as well start to discuss naming, too :-)
On Nov 24, 2004, at 11:09 AM, B. Bogart wrote:
to match the convension of gem
pdp_in and pdp_out would be best
(since we have sub-chains with prefixes in gem, pix_ vertex_ etc.. )
...I think this holds to the general design of gem, too; but...
[gem_pdp.out] and [gem_pdp.in] seem ok to me
or even
[out_pdp] and [in_pdp] to keep them shorter, since most gem objects don't have a gem_ prefix.
...I'm not sure that in and out are the best terms here? (although they aren't the worst, and make pretty good sense once ya see a patch)...
How about something more like [gem_to_pdp] & [gem_from_pdp]?
2 cents 2 late, jamie
James inspired me,
gem2pdp and pdp2gem or pix2pdp and pdp2pix
:)
Ok this time I'm really going to shut up and go back to work.
B.
...now that IOhannes has committed something, I may as well start to discuss naming, too :-)
On Nov 24, 2004, at 11:09 AM, B. Bogart wrote:
to match the convension of gem
pdp_in and pdp_out would be best
(since we have sub-chains with prefixes in gem, pix_ vertex_ etc.. )
...I think this holds to the general design of gem, too; but...
[gem_pdp.out] and [gem_pdp.in] seem ok to me
or even
[out_pdp] and [in_pdp] to keep them shorter, since most gem objects don't have a gem_ prefix.
...I'm not sure that in and out are the best terms here? (although they aren't the worst, and make pretty good sense once ya see a patch)...
How about something more like [gem_to_pdp] & [gem_from_pdp]?
2 cents 2 late, jamie
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
B. Bogart wrote:
James inspired me,
gem2pdp and pdp2gem or pix2pdp and pdp2pix
well, the problem is, that there already are [gem2pdp] and [pdp2gem] objects (thanks to yves)
and the new objects will work differently from the old ones (although both provide a bridge between gem and pdp)
but of course they are nice names (probably that is why they are already chosen)
mfg.a.dr IOhannes
Oops,
Of course the pdp_ objects start with pdp_ so my suggestion is illogical.
Do the objects only deal with pixel data? If so then pix_pdpin pix_pdpout may work...
Ok thats enough of me.
B.
since it's really only 'get' and 'set' (just about exchainging data with a gem render chain) i think this should be clear in the name.
the object qualify as 'gem chain objects' not pdp objects. so [pdp_xxx] seems confusing.
true. still i think that "pdp" should be in the name too, as [gem_set] wouldn't necessarily have something to do with pdp packages. so probably [gem_pdpout} and [gem_pdpin] would be more apropriate ? (or [gem_pdp.out] and [gem_pdp.in])
...
so the templates are almost done; just want to settle the name before i check them in
[gem_pdp.out] and [gem_pdp.in] seem ok to me
or even
[out_pdp] and [in_pdp] to keep them shorter, since most gem objects don't have a gem_ prefix.
yeah, politics!
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
hi,
i can compile current cvs but on loading gem states:
Gem.pd_linux: undefined symbol: glProgramEnvParameter4dARB Gem: can't load library
anybody else experienced this too ?
best
e
Erich Berger wrote:
hi,
i can compile current cvs but on loading gem states:
Gem.pd_linux: undefined symbol: glProgramEnvParameter4dARB Gem: can't load library
anybody else experienced this too ?
which openGL-drivers are you using ? which openGL-headers do you use to compile Gem ? (nvidia's ???)
mfg.ad.r IOhannes
which openGL-drivers are you using ? which openGL-headers do you use to compile Gem ? (nvidia's ???)
this is an old ati mach 64 chip on my laptop and i m using the experimental dri drivers from http://www.retinalburn.net/linux/dri_xv.html mach64-0-0-6-branch
so i guess this opengl extension is then not supportet. i ll compile it without the ogl stuff then.
best
e
hi,
since two days i m pondering on this problem.
i have 2 machines:
1) debian testing with old mach64 and experimental dri drivers 2) debian testing with nvidia GF4200Ti drivers 1.0-7174 headers installed and gem compiled with them
both run latest gem-cvs
the attached patch is a texture feedback with pix_alpha in a manner that black becomes alpha.
this works fine on the mach64, but not on the nvidia. see scrrenshots at: http://randomseed.org/mach64.gif http://randomseed.org/nvidia.gif
if u exchange pix_snap with pix_snap2tex then everything works as desired except on can not use pix_alpha anymore as the captured image is already textured.
anybody an idea what could be the reason ?
ps: on nvidia an image on the square appears when one sets the pix_coordinate parameter over 230, but it is a single feedback and the pix_alpha disappears in a certain area.
ps2: additionally creating the window results on both machines in: error Gem: Someone sent a bogus pointer to copy2Image error Gem: pix object [pix_alpha] cannot handle YUV image
isnt native colorspace rgba ?
thx for your help in advance
erich
Hey Erich,
on OSX I also get this with pix_snap, but I think it is that the bgcolour of the gemwin is set to alpha when copied with pix_snap. With pix_snap2tex things act "normal" that is the background colour is copied along with the other pixels with full opacity. I'm (also?) catitolizing on this "feature" in self-similar and so I hope it would stick around!
I have no tried this on linux in some time...
B.
Erich Berger wrote:
the attached patch is a texture feedback with pix_alpha in a manner that black becomes alpha.
hi ben,
which version do u get on OSX, the one with feedback working (mach64) or the other one (nvidia) (i guess the working one, as self similar would not quite produce similarities)
e
On Mon, 4 Apr 2005, B. Bogart wrote:
Hey Erich,
on OSX I also get this with pix_snap, but I think it is that the bgcolour of the gemwin is set to alpha when copied with pix_snap. With pix_snap2tex things act "normal" that is the background colour is copied along with the other pixels with full opacity. I'm (also?) catitolizing on this "feature" in self-similar and so I hope it would stick around!
I have no tried this on linux in some time...
B.
Erich Berger wrote:
the attached patch is a texture feedback with pix_alpha in a manner that black becomes alpha.
Erich Berger wrote:
hi,
since two days i m pondering on this problem.
i have 2 machines:
- debian testing with old mach64 and experimental dri drivers
- debian testing with nvidia GF4200Ti drivers 1.0-7174 headers installed and gem compiled with them
both run latest gem-cvs
the attached patch is a texture feedback with pix_alpha in a manner that black becomes alpha.
this works fine on the mach64, but not on the nvidia. see scrrenshots at: http://randomseed.org/mach64.gif http://randomseed.org/nvidia.gif
if u exchange pix_snap with pix_snap2tex then everything works as desired except on can not use pix_alpha anymore as the captured image is already textured.
anybody an idea what could be the reason ?
the problem is with with rectangle-textures which are supported by the new nvidia card but not by the old mach64. as a work-around (since i guess it is really a bug which should be fixed "upstream") try sending a "mode 0" message to [pix_texture] before doing the first snap to enforce the use of normalized textures.
i know that the texture is 256x256 (thus: normalized), but Gem still assumes that it is "rectangle" in order to benefit from some faster transmissions.
mfg.asdr IOhannes
hmmm,
Also I did not mention I *always* use pow(2,x) textures in my feedback patches...
B>
IOhannes m zmoelnig wrote:
Erich Berger wrote:
hi,
since two days i m pondering on this problem.
i have 2 machines:
- debian testing with old mach64 and experimental dri drivers
- debian testing with nvidia GF4200Ti drivers 1.0-7174 headers installed and gem compiled with them
both run latest gem-cvs
the attached patch is a texture feedback with pix_alpha in a manner that black becomes alpha.
this works fine on the mach64, but not on the nvidia. see scrrenshots at: http://randomseed.org/mach64.gif http://randomseed.org/nvidia.gif
if u exchange pix_snap with pix_snap2tex then everything works as desired except on can not use pix_alpha anymore as the captured image is already textured.
anybody an idea what could be the reason ?
the problem is with with rectangle-textures which are supported by the new nvidia card but not by the old mach64. as a work-around (since i guess it is really a bug which should be fixed "upstream") try sending a "mode 0" message to [pix_texture] before doing the first snap to enforce the use of normalized textures.
i know that the texture is 256x256 (thus: normalized), but Gem still assumes that it is "rectangle" in order to benefit from some faster transmissions.
mfg.asdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
B. Bogart wrote:
hmmm,
Also I did not mention I *always* use pow(2,x) textures in my feedback patches...
well yes, the thing is, that [pix_texture] prefers to use rectangle-texturing, even if the textures are normalized (this is 2^n) so if your card supports it and you don't object (by sending a [mode 0() you will always go into rectangle-texture-mode. i think this is fine on osX (good job jamie/chris) but not that foolproof on linux (who did that?)
mfg.asdr IOhannes
the problem is with with rectangle-textures which are supported by the new nvidia card but not by the old mach64. as a work-around (since i guess it is really a bug which should be fixed "upstream") try sending a "mode 0" message to [pix_texture] before doing the first snap to enforce the use of normalized textures.
indeed |mode 0( does the magic
merci
erich
i know that the texture is 256x256 (thus: normalized), but Gem still assumes that it is "rectangle" in order to benefit from some faster transmissions.
about the faster transmissions u mention: are they responsible for the following tabel ?
snap_size : 256 512 1024
cpu in % pix_snap : 5.3 61.9 98
cpu in% pix_snap2tex: 0 0 0
would there be such a huge difference between pix_snap and pix_snap2tex ?
best
erich
Erich Berger wrote:
i know that the texture is 256x256 (thus: normalized), but Gem still assumes that it is "rectangle" in order to benefit from some faster transmissions.
about the faster transmissions u mention: are they responsible for the following tabel ?
snap_size : 256 512 1024
cpu in % pix_snap : 5.3 61.9 98
cpu in% pix_snap2tex: 0 0 0
would there be such a huge difference between pix_snap and pix_snap2tex ?
this is the reason why there is [pix_snap2tex] in the first place: the bottle-neck with [pix_snap] is transferring the image from the gfx-card's memory into main-memory; this is slow if the data just stays on the gfx-card, this is _fast_
mfg.asdr IOhannes
would there be such a huge difference between pix_snap and pix_snap2tex ?
this is the reason why there is [pix_snap2tex] in the first place: the bottle-neck with [pix_snap] is transferring the image from the gfx-card's memory into main-memory; this is slow if the data just stays on the gfx-card, this is _fast_
which brings me logically to my next question: is there possibility to squeeze in a pix_alpha into the pix_snap2tex to have the benefit of both worlds ?
best
e
On Apr 3, 2005, at 8:58 AM, Erich Berger wrote:
i can compile current cvs but on loading gem states:
Gem.pd_linux: undefined symbol: glProgramEnvParameter4dARB Gem: can't load library
anybody else experienced this too ?
...hmm, this kind of stuff keeps coming up and reminding me that we have to do something about this :-)
...atm, we handle ARB and EXT testing at compile time, which means that things break if you use a binary compiled on a system that has support for advanced features on a system that doesn't...in this case, this is probably the first symbol you're not getting due to a lack of ARB_vertex_program in hardware...
...I'm not really sure how the gl headers work on linux: do they just define everything, or do they do checking of the capabilities of the system that they're on?
....it'd probably be better for us to adopt runtime extension checking, which we minimally do atm for texture_rectangle and client_storage (i think)...maybe we should use something like glew, or roll our own?
l8r, jamie
hi,
i just noticed that with pix_film on darwin the 3rd outlet does not give a bang when the movie is finished with playing. it should or ?
best
erich
Erich Berger wrote:
hi,
i just noticed that with pix_film on darwin the 3rd outlet does not give a bang when the movie is finished with playing. it should or ?
best
erich
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hi,
I do get a bang, using 0.90 Gem
Cheers, SFS
hello jamie, chris,
i m helping my friend with a gempatch on OSX we use the latest compile from jamies homepage.
the problem we have is that pix_film does not give a bang on the right outlet (like in linux for example) when the movie is finished.
is there a possibility for you to look into this ?
thx a lot
erich
Ok, I put a quick fix into CVS just now to bang at the end of a film. This is only a fix in 'auto 1' mode - I'm not sure why the bang is not sent when manually controlling playback using the right inlet. It is quite simple to test for this outside of the object itself using the second outlet.
cgc
On 11/8/05, Erich Berger eb@randomseed.org wrote:
hello jamie, chris,
i m helping my friend with a gempatch on OSX we use the latest compile from jamies homepage.
the problem we have is that pix_film does not give a bang on the right outlet (like in linux for example) when the movie is finished.
is there a possibility for you to look into this ?
thx a lot
erich
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
thx a lot
erich
--------------------- http://randomseed.org
On Tue, 8 Nov 2005, chris clepper wrote:
Ok, I put a quick fix into CVS just now to bang at the end of a film. This is only a fix in 'auto 1' mode - I'm not sure why the bang is not sent when manually controlling playback using the right inlet. It is quite simple to test for this outside of the object itself using the second outlet.
cgc
On 11/8/05, Erich Berger eb@randomseed.org wrote:
hello jamie, chris,
i m helping my friend with a gempatch on OSX we use the latest compile from jamies homepage.
the problem we have is that pix_film does not give a bang on the right outlet (like in linux for example) when the movie is finished.
is there a possibility for you to look into this ?
thx a lot
erich
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hi,
i finally got to test the fix from chris.
Ok, I put a quick fix into CVS just now to bang at the end of a film. This is only a fix in 'auto 1' mode - I'm not sure why the bang is not sent when manually controlling playback using the right inlet. It is quite simple to test for this outside of the object itself using the second outlet.
my friend needs to use the automode that the sound of the video is playing. in manual mode there is no sound.
now after the fix there is a bang in automode at the end of the file. this bang i can now use to turn off auto 1. the problem is that the audio as then still played once again (audio only).
is there a way to fix this ?
the behaviour of the linux object is a bit different and actually quite useful.
if u put the object in auto 1 mode it will play the film until the end, stops and bangs from the right outlet. until it receives a message into the right inlet at which frame it should continue it does not start again. in this way i m in full control over the auto loop.
because of this project i tried out pix_film on linux (my native) win and osx. on each platform the object is different. i would say on linux it has an optimal behaviour only that we had a massive codec problem. on windows it worked fine but without sound, and the problem on osx is descussed at the beginning of the mail.
about the build process of gem under osx is it now a commandline build like under linux oder do i need to setup a special environment ?
thx for all the help
cheers
erich
Erich Berger wrote:
because of this project i tried out pix_film on linux (my native) win and osx. on each platform the object is different. i would say on linux it has an optimal behaviour only that we had a massive codec problem. on windows it worked fine but without sound, and the problem on osx
but if you need sound, the object on linux won't give it to you either.
is descussed at the beginning of the mail.
about the build process of gem under osx is it now a commandline build like under linux oder do i need to setup a special environment ?
i use to compile Gem from the command line (the mac i use to compile is in the roomnext to me and i don't want to switch rooms just to test whether my code changes break the build on OSX)(darn, i'd love to have that for w32 too) this produces a binary that is at least loadable by Gem (since there is no X on osX i cannot test it remotely
mfg.adsr. IOhannes
but if you need sound, the object on linux won't give it to you either.
she is anyway working on mac so thats fine - just wanted to point it out.
i use to compile Gem from the command line (the mac i use to compile is in
well i then have to giv it a try as well
e
On 11/22/05, Erich Berger eb@randomseed.org wrote:
hi,
i finally got to test the fix from chris.
Ok, I put a quick fix into CVS just now to bang at the end of a film. This is only a fix in 'auto 1' mode - I'm not sure why the bang is not sent when manually controlling playback using the right inlet. It is quite simple to test for this outside of the object itself using the second outlet.
my friend needs to use the automode that the sound of the video is playing. in manual mode there is no sound.
now after the fix there is a bang in automode at the end of the file. this bang i can now use to turn off auto 1. the problem is that the audio as then still played once again (audio only).
is there a way to fix this ?
pix_film/movie are designed to handle video only, so sound does behave oddly using pix_film/movie. It's really only in there by accident and because I made a special build for my friend to use at one point. I obviously never checked in that build because it had volume control as I recall.
the behaviour of the linux object is a bit different and actually quite useful.
if u put the object in auto 1 mode it will play the film until the end, stops and bangs from the right outlet. until it receives a message into the right inlet at which frame it should continue it does not start again. in this way i m in full control over the auto loop.
Auto mode on OSX hands off all of the movie tasking to Quicktime because it resulted in much better playback with multiple movies at once. It's not good that the behavior between platforms is different, but then again we've tried to make the Quicktime related objects work as well as possible and not work against us.
about the build process of gem under osx is it now a commandline build like under linux oder do i need to setup a special environment ?
We use the XCode project to maintain and build GEM on OSX. It's free and comes with the OS in most cases, but you have to learn it and also sort out the libs like FTGL.
hello,
pix_film/movie are designed to handle video only, so sound does behave oddly using pix_film/movie. It's really only in there by accident and because I made a special build for my friend to use at one point. I obviously never checked in that build because it had volume control as I recall.
thx chris - i understand now. but if there is a way to stop whatever (object or quicktime) for repeating the sound once after it was switched to auto 0 then it would actually work.
would this be possible ?
best
erich
On 11/24/05, Erich Berger eb@randomseed.org wrote:
thx chris - i understand now. but if there is a way to stop whatever (object or quicktime) for repeating the sound once after it was switched to auto 0 then it would actually work.
would this be possible ?
I'm working on it, but it doesn't look like an obvious quick fix to me. I may add a 'loop $1' type message to force single shot playback. I also need to figure out a fix for the sound continuing after rendering stops.
Here's a real 'duh' answer: put the right outlet bang through a [delay 10] and have that bang a [1( or whatever frame number you want into the right inlet. That will stop the playback on that frame and the sound. Part of the problem is the sync between the internal states and Pd messaging, which is why the delay is needed.
I will hopefully come up with something better in the near future.
On 11/24/05, Erich Berger eb@randomseed.org wrote:
thx chris - i understand now. but if there is a way to stop whatever (object or quicktime) for repeating the sound once after it was switched to auto 0 then it would actually work.
would this be possible ?
best
erich
Here's a real 'duh' answer: put the right outlet bang through a [delay 10] and have that bang a [1( or whatever frame number you want into the right inlet. That will stop the playback on that frame and the sound. Part of the problem is the sync between the internal states and Pd messaging, which is why the delay is needed.
hi chris - the workaround is doing its job ! thx a lot for helping out
erich
hi,
i have some question regarding memory management and pix_video. a friend of mine is using it for playing in some certain order about 70 small clips for an installation. she had it test running the whole night and reported that is was becoming extremly slow when she had a look at it in the morning. i had no possibility to check the stuff but i guess that it is because the memory got full by constantly loading the clips.
now the questions:
when pix_video is loading another clip, is it freeing the memory which took the clip played before or does it stay in the memory ?
when the same clip is played again after playing another one is it loaded again into the memory or is the one already loaded before used again ?
is there a method to clear the memory taken over by all this loaded films without restarting pd ?
best
erich
I think you mean pix_film or pix_movie. What OS and GEM version?
On 5/11/06, Erich Berger eb@randomseed.org wrote:
hi,
i have some question regarding memory management and pix_video. a friend of mine is using it for playing in some certain order about 70 small clips for an installation. she had it test running the whole night and reported that is was becoming extremly slow when she had a look at it in the morning. i had no possibility to check the stuff but i guess that it is because the memory got full by constantly loading the clips.
now the questions:
when pix_video is loading another clip, is it freeing the memory which took the clip played before or does it stay in the memory ?
when the same clip is played again after playing another one is it loaded again into the memory or is the one already loaded before used again ?
is there a method to clear the memory taken over by all this loaded films without restarting pd ?
best
erich
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hi chris,
of course pix_film ! - she is using osx on a minimac with the version u have commited a bug fix (for pix_fim) on 8th of november.
best
erich
--------------------- http://randomseed.org
On Thu, 11 May 2006, chris clepper wrote:
I think you mean pix_film or pix_movie. What OS and GEM version?
On 5/11/06, Erich Berger eb@randomseed.org wrote:
hi,
i have some question regarding memory management and pix_video. a friend of mine is using it for playing in some certain order about 70 small clips for an installation. she had it test running the whole night and reported that is was becoming extremly slow when she had a look at it in the morning. i had no possibility to check the stuff but i guess that it is because the memory got full by constantly loading the clips.
now the questions:
when pix_video is loading another clip, is it freeing the memory which took the clip played before or does it stay in the memory ?
when the same clip is played again after playing another one is it loaded again into the memory or is the one already loaded before used again ?
is there a method to clear the memory taken over by all this loaded films without restarting pd ?
best
erich
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hey all,
On May 11, 2006, at 9:05 AM, Erich Berger wrote:
of course pix_film !
- she is using osx on a minimac with the
version u have commited a bug fix (for pix_fim) on 8th of november.
On Thu, 11 May 2006, chris clepper wrote:
I think you mean pix_film or pix_movie. What OS and GEM version?
On 5/11/06, Erich Berger eb@randomseed.org wrote:
hi, i have some question regarding memory management and pix_video. a friend of mine is using it for playing in some certain order about 70 small clips for an installation. she had it test running the whole night and reported that is was becoming extremly slow when she had a look at it in the morning. i had no possibility to check the stuff but i guess that it is because the memory got full by constantly loading the clips. now the questions: when pix_video is loading another clip, is it freeing the memory which took the clip played before or does it stay in the memory ? when the same clip is played again after playing another one is it loaded again into the memory or is the one already loaded before used again ? is there a method to clear the memory taken over by all this loaded films without restarting pd ?
...hmm, I'm looking at [pix_film] and whaddaya know? There seems to be all kinds of stuff going weird with createBuffer(), deleteBuffer (), and prepareTexture() :-( First off, pix_film::openMess() has:
#ifndef __APPLE__ createBuffer(); prepareTexture(); #endif
...this may be a relic/hack from waaaay back?
...but this occurs AFTER pix_film::openMess() calls realOpen(), which is in pix_filmDarwin.cpp...this may be significant because in pix_filmDarwin::realOpen() we call the same things (or not) based on the value of m_colorspace (BGRA or other)...
...also, pix_film::createBuffer() will never cache the buffer because oldx and oldy aren't member variables AND they're always set to 0, so we always hit this:
if (neededXSize != oldx || neededYSize != oldy) { deleteBuffer(); ... }
...um, and that's as far as I've gotten: I'll give some of these ideas a test, but won't have much time until, uh, later...
jamie
I'm not sure if any of that matters. I haven't seen any problems with the pix_film object and my testing is up to several million files and many thousands of hours.
At this point problems are likely to be Quicktime issues related to specific codecs.
On 5/11/06, james tittle tigital@mac.com wrote:
...hmm, I'm looking at [pix_film] and whaddaya know? There seems to be all kinds of stuff going weird with createBuffer(), deleteBuffer (), and prepareTexture() :-( First off, pix_film::openMess() has:
#ifndef __APPLE__ createBuffer(); prepareTexture(); #endif
...this may be a relic/hack from waaaay back?
...but this occurs AFTER pix_film::openMess() calls realOpen(), which is in pix_filmDarwin.cpp...this may be significant because in pix_filmDarwin::realOpen() we call the same things (or not) based on the value of m_colorspace (BGRA or other)...
...also, pix_film::createBuffer() will never cache the buffer because oldx and oldy aren't member variables AND they're always set to 0, so we always hit this:
if (neededXSize != oldx || neededYSize != oldy) { deleteBuffer(); ... }
...um, and that's as far as I've gotten: I'll give some of these ideas a test, but won't have much time until, uh, later...
jamie
On May 11, 2006, at 1:20 PM, chris clepper wrote:
I'm not sure if any of that matters. I haven't seen any problems with the pix_film object and my testing is up to several million files and many thousands of hours.
At this point problems are likely to be Quicktime issues related to specific codecs.
...yeh, closer inspection shows that prepareTexture() is only used pix_movie-derivatives, or else is an empty function...and of course I mis-read the "#ifndef", so I was thinking we were double-requesting buffers...however, the cache stuff is real, and a simple fix, but not probably germaine to the problem here...
...I'll try to set up some testing overnight here, and see if I can see any of this problem...
sigh, jamie
On 5/11/06, james tittle tigital@mac.com wrote:
...hmm, I'm looking at [pix_film] and whaddaya know? There seems to be all kinds of stuff going weird with createBuffer(), deleteBuffer (), and prepareTexture() :-( First off, pix_film::openMess() has:
#ifndef __APPLE__ createBuffer(); prepareTexture(); #endif
...this may be a relic/hack from waaaay back?
...but this occurs AFTER pix_film::openMess() calls realOpen(), which is in pix_filmDarwin.cpp...this may be significant because in pix_filmDarwin::realOpen() we call the same things (or not) based on the value of m_colorspace (BGRA or other)...
...also, pix_film::createBuffer() will never cache the buffer because oldx and oldy aren't member variables AND they're always set to 0, so we always hit this:
if (neededXSize != oldx || neededYSize != oldy) { deleteBuffer(); ... }
...um, and that's as far as I've gotten: I'll give some of these ideas a test, but won't have much time until, uh, later...
jamie
hi chris/james,
i will see the specific patch/machine on monday, then i can give more specific info about codec etc.
but just to make it clear for me: is pix_film unloading the previous film from the memory when a new one is loaded or does it remain in memory ?
best + thx
erich
--------------------- http://randomseed.org
On Thu, 11 May 2006, james tittle wrote:
On May 11, 2006, at 1:20 PM, chris clepper wrote:
I'm not sure if any of that matters. I haven't seen any problems with the pix_film object and my testing is up to several million files and many thousands of hours.
At this point problems are likely to be Quicktime issues related to specific codecs.
...yeh, closer inspection shows that prepareTexture() is only used pix_movie-derivatives, or else is an empty function...and of course I mis-read the "#ifndef", so I was thinking we were double-requesting buffers...however, the cache stuff is real, and a simple fix, but not probably germaine to the problem here...
...I'll try to set up some testing overnight here, and see if I can see any of this problem...
sigh, jamie
On 5/11/06, james tittle tigital@mac.com wrote:
...hmm, I'm looking at [pix_film] and whaddaya know? There seems to be all kinds of stuff going weird with createBuffer(), deleteBuffer (), and prepareTexture() :-( First off, pix_film::openMess() has:
#ifndef __APPLE__ createBuffer(); prepareTexture(); #endif
...this may be a relic/hack from waaaay back?
...but this occurs AFTER pix_film::openMess() calls realOpen(), which is in pix_filmDarwin.cpp...this may be significant because in pix_filmDarwin::realOpen() we call the same things (or not) based on the value of m_colorspace (BGRA or other)...
...also, pix_film::createBuffer() will never cache the buffer because oldx and oldy aren't member variables AND they're always set to 0, so we always hit this:
if (neededXSize != oldx || neededYSize != oldy) { deleteBuffer(); ... }
...um, and that's as far as I've gotten: I'll give some of these ideas a test, but won't have much time until, uh, later...
jamie
On 5/12/06, Erich Berger eb@randomseed.org wrote:
but just to make it clear for me: is pix_film unloading the previous film from the memory when a new one is loaded or does it remain in memory ?
Only one frame is loaded into memory at a time by GEM. Quicktime may establish it's own buffers depending on the codec type which is a process we have no control over. I haven't seen any memory leaks from pix_film/movie on OSX and pieces using up to 16 of those objects have run for many months (wndows is a different story though).
cgc
On May 12, 2006, at 8:40 AM, chris clepper wrote:
On 5/12/06, Erich Berger eb@randomseed.org wrote: but just to make it clear for me: is pix_film unloading the previous film from the memory when a new one is loaded or does it remain in memory ?
Only one frame is loaded into memory at a time by GEM. Quicktime may establish it's own buffers depending on the codec type which is a process we have no control over. I haven't seen any memory leaks from pix_film/movie on OSX and pieces using up to 16 of those objects have run for many months (wndows is a different story though).
...just wanted to add that besides the per frame memory loading/ unloading, [pix_film] also takes care to cleanup movie "containers" (ie. .mov or .avi) if a previous film was open when a second one is requested (ie. loading new films)...
...things of interest to know would be how many clips are being opened/closed and how often, and at what frame rate the project is running...
l8r, jamie
hi,
i was just sitting in front of the machine (minimac) and watching the pd processes while my friends app is running.
the memory use increases about a rate of 1MB per minute.
her movie codec is: integer(big endian), animation. she took this as a choice to get the the alpha channel - did you test this as well ? audio: linear pcm 44.100
can you recommend a codec with alpha were you had no problems ? if we get the same results then we can at least rule out the codecs.
maybe there is a leak somewhere else, she is using additionally:
text2d pix_alpha
is there any known issue with this 2 objects ?
thx for the help
best
erich
--------------------- http://randomseed.org
On Fri, 12 May 2006, chris clepper wrote:
On 5/12/06, Erich Berger eb@randomseed.org wrote:
but just to make it clear for me: is pix_film unloading the previous film from the memory when a new one is loaded or does it remain in memory ?
Only one frame is loaded into memory at a time by GEM. Quicktime may establish it's own buffers depending on the codec type which is a process we have no control over. I haven't seen any memory leaks from pix_film/movie on OSX and pieces using up to 16 of those objects have run for many months (wndows is a different story though).
cgc
On 5/15/06, Erich Berger eb@randomseed.org wrote:
hi,
i was just sitting in front of the machine (minimac) and watching the pd processes while my friends app is running.
Intel or G4 Mini?
the memory use increases about a rate of 1MB per minute.
her movie codec is: integer(big endian), animation. she took this as a choice to get the the alpha channel - did you test this as well ? audio: linear pcm 44.100
I have used Animation recently (on Intel in fact) and did not see such a leak.
can you recommend a codec with alpha were
you had no problems ? if we get the same results then we can at least rule out the codecs.
Animation is probably the best choice when a pre rendered alpha is needed.
maybe there is a leak somewhere else,
she is using additionally:
text2d
This is a possible culprit as it is part of a lib we do not write ourselves.
pix_alpha
There is no memory allocation in this object.
hi chris,
Intel or G4 Mini?
G4 mini
Animation is probably the best choice when a pre rendered alpha is needed.
good
maybe there is a leak somewhere else,
she is using additionally:
text2d
This is a possible culprit as it is part of a lib we do not write ourselves.
ok - i ll test this one - separate from pix_film
thx
best
erich
text2d
This is a possible culprit as it is part of a lib we do not write ourselves.
and it is. text 2d/3d seems not to free the memory when one is rendering a new sentence. my friend built a subtitle engine for her movies and so there is a lot of text. one can really see the mem increase with every line of new text.
is there a solution to this problem or should she start to make text/tiffs asap :-) ?
best
erich
Erich Berger wrote:
text2d
This is a possible culprit as it is part of a lib we do not write ourselves.
and it is. text 2d/3d seems not to free the memory when one is rendering a new sentence. my friend built a subtitle engine for her movies and so there is a lot of text. one can really see the mem increase with every line of new text.
just to be sure: the memleak _is_ in text2d/3d or is it rather in the the symbol-table of pd? (you cannot generate an infinite number of symbols in pd without introducing a memleak; you can't even avoid it as long as pd has no "string" type and symbols are stored in a hashtable.)
this doesn't mean however, that there is no memleak in text*. could you send me a small test-patch that exposes this behaviour?
mg.hsf.dt IOhannes
is there a solution to this problem or should she start to make text/tiffs asap :-) ?
best
erich
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hallo, Erich Berger hat gesagt: // Erich Berger wrote:
and it is. text 2d/3d seems not to free the memory when one is rendering a new sentence. my friend built a subtitle engine for her movies and so there is a lot of text. one can really see the mem increase with every line of new text.
I think this could also be the fault of Pd's symbol table filling up quickly.
Ciao
I think this could also be the fault of Pd's symbol table filling up quickly.
hmm - but i m talking about 100k per sentence - could this be the symbol table ?
best
erich
--------------------- http://randomseed.org
Erich Berger wrote:
I think this could also be the fault of Pd's symbol table filling up quickly.
hmm - but i m talking about 100k per sentence - could this be the symbol table ?
best way to try is to use always the same symbols. (or alternate between 2 sets of symbols.) this would have a constant symbol table and if the memleak still occurs, then it is within [text2d]. another possibility would be to disconnnect the [text*] object from the text-strings and see if it is still there.
fga.dsr IOhannes
uff - if i m not completley off then pd itself eats about 30k per second. its version 39.1 on G4 minimac - no lib loaded - no patch loaded
i m watching the pd process with top on a terminal - it just constantly counts up the rsize value
best
e
ps - i ll look for newer versions
--------------------- http://randomseed.org
On Mon, 15 May 2006, IOhannes m zmoelnig wrote:
Erich Berger wrote:
I think this could also be the fault of Pd's symbol table filling up quickly.
hmm - but i m talking about 100k per sentence - could this be the symbol table ?
best way to try is to use always the same symbols. (or alternate between 2 sets of symbols.) this would have a constant symbol table and if the memleak still occurs, then it is within [text2d]. another possibility would be to disconnnect the [text*] object from the text-strings and see if it is still there.
fga.dsr IOhannes
hi gem-devs
i hereby officially apologize for blaming gem first as reason for the leak
best
erich_;-)
On 5/15/06, Erich Berger eb@randomseed.org wrote:
uff - if i m not completley off then pd itself eats about 30k per second. its version 39.1 on G4 minimac - no lib loaded - no patch loaded
i m watching the pd process with top on a terminal - it just constantly counts up the rsize value
best
e
ps - i ll look for newer versions
Try the -noaudio -nomidi flags if you don't need those. I think there might be a memleak in the portaudio code.
I use 0.37-4 for long term installations. That's the last version I found without significant issues on the Mac.
hi,
39.2 also seems to be clean.
but anyway it seems i m fighting tonight.
i put Gem.pd_darwin into the extra folder of the app. the rights are set ok, but Gem does not load, pd finds it but can not load the lib. other libs in this dir are loaded fine.
it happens with pd 39.2 and 38.3 and with the Gem.pd_darwin s from tigitals website and the one which is in use with my pd 39.1.
and yes there is also "Gem" in the startup - same prefs open also successfully the old 39.1/Gem combi it was running on before ...
lost - please open my eyes
e
--------------------- http://randomseed.org
On Mon, 15 May 2006, chris clepper wrote:
On 5/15/06, Erich Berger eb@randomseed.org wrote:
uff - if i m not completley off then pd itself eats about 30k per second. its version 39.1 on G4 minimac - no lib loaded - no patch loaded
i m watching the pd process with top on a terminal - it just constantly counts up the rsize value
best
e
ps - i ll look for newer versions
Try the -noaudio -nomidi flags if you don't need those. I think there might be a memleak in the portaudio code.
I use 0.37-4 for long term installations. That's the last version I found without significant issues on the Mac.
hi,
finally running without memory problems using hc's 39.2-test3 installer.
still no idea why gem does not open with the binaries combination miller(pd)/tigital(gem) but stopped trying after it worked with hc's.
the leaking pd39.1 is btw the pd++ from tigitals (hi jamie :-) mac page.
thanks to all of you for helping me on the way !!
cheers
erich
--------------------- http://randomseed.org
On Mon, 15 May 2006, Erich Berger wrote:
hi,
39.2 also seems to be clean.
but anyway it seems i m fighting tonight.
i put Gem.pd_darwin into the extra folder of the app. the rights are set ok, but Gem does not load, pd finds it but can not load the lib. other libs in this dir are loaded fine.
it happens with pd 39.2 and 38.3 and with the Gem.pd_darwin s from tigitals website and the one which is in use with my pd 39.1.
and yes there is also "Gem" in the startup - same prefs open also successfully the old 39.1/Gem combi it was running on before ...
lost - please open my eyes
e
On Mon, 15 May 2006, chris clepper wrote:
On 5/15/06, Erich Berger eb@randomseed.org wrote:
uff - if i m not completley off then pd itself eats about 30k per second. its version 39.1 on G4 minimac - no lib loaded - no patch loaded
i m watching the pd process with top on a terminal - it just constantly counts up the rsize value
best
e
ps - i ll look for newer versions
Try the -noaudio -nomidi flags if you don't need those. I think there might be a memleak in the portaudio code.
I use 0.37-4 for long term installations. That's the last version I found without significant issues on the Mac.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hello, when one uses alpha (alpha makes the bug visible) on a cube or cuboid (thats the geos i tested), and switches with the draw messages to wireframe and back the rendering of the objects becomes wrong. it actually is already enough to only send a draw fill message to mess it up. attached you find a patch to demonstrate it.
i would be very happy if somebody could fix this as i m using it in a work under development.
best + thx
erich --------------------- http://randomseed.org
hey,
On Aug 11, 2006, at 5:09 AM, Erich Berger wrote:
when one uses alpha (alpha makes the bug visible) on a cube or cuboid (thats the geos i tested), and switches with the draw messages to wireframe and back the rendering of the objects becomes wrong. it actually is already enough to only send a draw fill message to mess it up. attached you find a patch to demonstrate it.
...luckily, it's not so much a bug, as it is an odd implementation ;-) The default draw style of cube is GL_QUADS, and you can get this either by [draw default< or [draw Quads<
[draw fill< actually switches it to GL_POLYGON...so this may point out that we need a different order of vertices/faces to create the expected shading...
jamie
-
B. Bogart -
chris clepper -
chris clepper -
Erich Berger -
Frank Barknecht -
IOhannes m zmoelnig -
james tittle -
Johannes M Zmoelnig
-
slimboyfatboyslim -
Tom Schouten