Re: [GEM-dev] [ pd-gem-Bugs-3177253 ] pix_crop does not work anymore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-02-11 19:31, cyrille henry wrote: hello, i update Gem on my main laptop. i notice a very important performance drop. rendering multiples primitives (using repeat by example) uses lot's more CPU than it use to. some of my patch are more than 2 times slower... darn. i also noticed some crash, but did not have something that i can reproduce. do you prefers reporting regression on this ML, or on SF bug tracker? i guess this ML is ok. gfmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1Y6A8ACgkQkX2Xpv6ydvTnkACgsAvQb4M6EiERroGFUvSXEzis O2MAnjoARwfZan8IdulmjeeV13WUkpcj =78vP -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
[GEM-dev] update: frei0r
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 i thought it might be a good idea to inform you: Gem now comes with a simple frei0r wrapper, that allows you to use frei0r source and effect plugins (though not mixer plugins, atm), just like FreeFrame effects. syntax: [pix_frei0r pluginname] alternatively: [pix_pluginname] fmnasdrt IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1Y8+oACgkQkX2Xpv6ydvR13wCfUKVk7GfP+OwKm1VVqU95HN91 fEMAn0DiBJUTDcokZOnwOPfEeVz5Rxj3 =QymF -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
[GEM-dev] updated: glsl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 i thought it might be a good idea to inform you: glsl_ objects now stopped emitting the shader-IDs for each and every frame. instead, the shaderID is emitted only once, when the shaders are loaded. thus you won't need the [change] object anymore, to prevent [glsl_program] to link a new program for each frame. caveat: currently only valid shaders are sent; if linking fails, you don't know (should be (if needed): 0) fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1Y9JIACgkQkX2Xpv6ydvR5qwCdGswUxLOAoXpBokLqDQbZmDAO A3kAoLMjtN8KoHbQ+AuCTwQp+cm1XlYQ =0OXa -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
[GEM-dev] weirdeness : WAS Re: [ pd-gem-Bugs-3177253 ] pix_crop does not work anymore
hello Le 14/02/2011 09:30, IOhannes m zmoelnig a écrit : some of my patch are more than 2 times slower... darn. does that mean this is a huge problem, i put it on top of my priority. or oups, we're doomed ? i also noticed some crash, but did not have something that i can reproduce. do you prefers reporting regression on this ML, or on SF bug tracker? i guess this ML is ok. ok. it look like the crash get fixed anyway. is it normal that every pix_blablabla object get instancied as a pix_freeframe object? (with a error: GemException: couldn't find 'blablabla'.'') cheers Cyrille ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] updated: glsl
Le 14/02/2011 10:23, IOhannes m zmoelnig a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 i thought it might be a good idea to inform you: glsl_ objects now stopped emitting the shader-IDs for each and every frame. nice instead, the shaderID is emitted only once, when the shaders are loaded. thus you won't need the [change] object anymore, to prevent [glsl_program] to link a new program for each frame. caveat: currently only valid shaders are sent; if linking fails, you don't know (should be (if needed): 0) if it fail, there is an error in pd log. I think it's ok. thanks c fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1Y9JIACgkQkX2Xpv6ydvR5qwCdGswUxLOAoXpBokLqDQbZmDAO A3kAoLMjtN8KoHbQ+AuCTwQp+cm1XlYQ =0OXa -END PGP SIGNATURE- ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] updated: glsl
Yep, good new ! ++ Jack Le lundi 14 février 2011 à 12:12 +0100, cyrille henry a écrit : Le 14/02/2011 10:23, IOhannes m zmoelnig a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 i thought it might be a good idea to inform you: glsl_ objects now stopped emitting the shader-IDs for each and every frame. nice instead, the shaderID is emitted only once, when the shaders are loaded. thus you won't need the [change] object anymore, to prevent [glsl_program] to link a new program for each frame. caveat: currently only valid shaders are sent; if linking fails, you don't know (should be (if needed): 0) if it fail, there is an error in pd log. I think it's ok. thanks c fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1Y9JIACgkQkX2Xpv6ydvR5qwCdGswUxLOAoXpBokLqDQbZmDAO A3kAoLMjtN8KoHbQ+AuCTwQp+cm1XlYQ =0OXa -END PGP SIGNATURE- ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev signature.asc Description: This is a digitally signed message part ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] updated: glsl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-02-14 12:12, cyrille henry wrote: caveat: currently only valid shaders are sent; if linking fails, you don't know (should be (if needed): 0) if it fail, there is an error in pd log. I think it's ok. that's why it is not high on my todo list :-) generally i think it's nicer if you get feedback in the patch as well, so you can programmatically react on it... fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1ZEVoACgkQkX2Xpv6ydvTW+ACg2LVvw7Hj4OqWIFhF6buUoWFu 5xgAoJZOCzdQpYr/aXvFz+V1yVXhojVH =w5gR -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] weirdeness : WAS Re: [ pd-gem-Bugs-3177253 ] pix_crop does not work anymore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-02-14 12:06, cyrille henry wrote: hello Le 14/02/2011 09:30, IOhannes m zmoelnig a écrit : some of my patch are more than 2 times slower... darn. does that mean this is a huge problem, i put it on top of my priority. or oups, we're doomed ? i'm not sure yet. it's not on TOP of my priority list, but it is something i need to evaluate and probably come up with a better solution. the architectural change was done in order to make the render-chain more modular, so 3rd party objects could be used with various Gem releases without the need to re-compile. right now, i think that only pix_ objects should be affected by the slow-down; is this correct? fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1ZErgACgkQkX2Xpv6ydvQQcACg6crTWOK11Cb5wxNwfWuJ+3sU 5X4AoI52WpEiMXvLDQ1Z6KugTC6a9NeZ =Qinr -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] weirdeness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-02-14 12:06, cyrille henry wrote: is it normal that every pix_blablabla object get instancied as a pix_freeframe object? yes this is normal. FreeFrame (and frei0r) also register loaders, so you can instantiate these effects as [pix_pluginname]. (with a error: GemException: couldn't find 'blablabla'.'') could be that i increased verbosity with one of the last commits, so you actually notice that freeframe is involved (as opposed to the object simply failing to create) just to make sure: freeframe/frei0r loaders should only take effect if there is actually such a plugin. e.g. if you create [pix_blabla] and there is no FreeFrame plugin named blabla but there is an abstraction pix_blabla.pd in your path, you should still end up with the abstraction. fg asdrm IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1ZE8QACgkQkX2Xpv6ydvRjAQCgnI6g9PAF1BO8bOyImNY0zAgD v7gAoMlGvxC6mL6WXYhQGrW1lxvxuRTq =etwb -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] weirdeness
It is strange to see the object [pix_blabla] created and get in the console : error: GemException: couldn't find 'blabla'.'' And a 'help' on this object and i get : sorry, couldn't find help patch for pix_freeframe.pd ++ Jack Le lundi 14 février 2011 à 12:36 +0100, IOhannes m zmoelnig a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-02-14 12:06, cyrille henry wrote: is it normal that every pix_blablabla object get instancied as a pix_freeframe object? yes this is normal. FreeFrame (and frei0r) also register loaders, so you can instantiate these effects as [pix_pluginname]. (with a error: GemException: couldn't find 'blablabla'.'') could be that i increased verbosity with one of the last commits, so you actually notice that freeframe is involved (as opposed to the object simply failing to create) just to make sure: freeframe/frei0r loaders should only take effect if there is actually such a plugin. e.g. if you create [pix_blabla] and there is no FreeFrame plugin named blabla but there is an abstraction pix_blabla.pd in your path, you should still end up with the abstraction. fg asdrm IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1ZE8QACgkQkX2Xpv6ydvRjAQCgnI6g9PAF1BO8bOyImNY0zAgD v7gAoMlGvxC6mL6WXYhQGrW1lxvxuRTq =etwb -END PGP SIGNATURE- ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev signature.asc Description: This is a digitally signed message part ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] weirdeness
Le 14/02/2011 12:36, IOhannes m zmoelnig a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-02-14 12:06, cyrille henry wrote: is it normal that every pix_blablabla object get instancied as a pix_freeframe object? yes this is normal. FreeFrame (and frei0r) also register loaders, so you can instantiate these effects as [pix_pluginname]. (with a error: GemException: couldn't find 'blablabla'.'') could be that i increased verbosity with one of the last commits, so you actually notice that freeframe is involved (as opposed to the object simply failing to create) just to make sure: freeframe/frei0r loaders should only take effect if there is actually such a plugin. e.g. if you create [pix_blabla] and there is no FreeFrame plugin named blabla but there is an abstraction pix_blabla.pd in your path, you should still end up with the abstraction. if there is no freeframe plugin, and no abstraction, then what is the pix_blabla object? something that don't do anything? except breaking connection of your patch, since this object have only 1 inlet. so, i think it would be more logic that pix_blabla does not instantiate. but that's not really important. c fg asdrm IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1ZE8QACgkQkX2Xpv6ydvRjAQCgnI6g9PAF1BO8bOyImNY0zAgD v7gAoMlGvxC6mL6WXYhQGrW1lxvxuRTq =etwb -END PGP SIGNATURE- ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] weirdeness : WAS Re: [ pd-gem-Bugs-3177253 ] pix_crop does not work anymore
Le 14/02/2011 12:32, IOhannes m zmoelnig a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-02-14 12:06, cyrille henry wrote: hello Le 14/02/2011 09:30, IOhannes m zmoelnig a écrit : some of my patch are more than 2 times slower... darn. does that mean this is a huge problem, i put it on top of my priority. or oups, we're doomed ? i'm not sure yet. it's not on TOP of my priority list, but it is something i need to evaluate and probably come up with a better solution. the architectural change was done in order to make the render-chain more modular, so 3rd party objects could be used with various Gem releases without the need to re-compile. ok, cool. right now, i think that only pix_ objects should be affected by the slow-down; is this correct? no. using patch in help folder/02.advanced/22.double-iterative.pd changing 20 to 100 in both message in order to render lot's more cube. using Gem svn from 20101231, it use about 68% of my CPU using current svn gives 104% i've got other patch where the difference is more important, but none of them use pix objects. C ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] weirdeness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-02-14 13:17, cyrille henry wrote: Le 14/02/2011 13:13, IOhannes m zmoelnig a écrit : ah, i think i start to understand. what you describe is definitely a bug, as in this case [pix_blabla] should fail to instantiate. ok, good. we agree. fixed. fgasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1ZIdEACgkQkX2Xpv6ydvTSvgCfWf7hdL6nktQv9O5nhRjXZdv4 S28An2CZlNaA1qo9KdEsB5di6YeDCzmu =+ilf -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
[GEM-dev] [pix_video] osx (fwd)
-- Forwarded message -- Date: Mon, 14 Feb 2011 08:43:11 -0500 (EST) From: Mathieu Bouchard ma...@artengine.ca To: IOhannes m zmoelnig zmoel...@iem.at Subject: [pix_video] osx Did you know that in gem 92, the device method of [pix_video] seems to have no effect ? I had to use two [pix_video] : one to force opening of the first camera, and one to get the other first remaining camera. It looks really weird. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] [pix_video] osx (fwd)
The messages are different on OSX because devices can and do have multiple inputs. Selecting a 'device' only is not enough information to tell the driver of something like a Blackmagic Intensity card so you need to add an 'input' message as well. On Mon, Feb 14, 2011 at 9:47 AM, Mathieu Bouchard ma...@artengine.cawrote: -- Forwarded message -- Date: Mon, 14 Feb 2011 08:43:11 -0500 (EST) From: Mathieu Bouchard ma...@artengine.ca To: IOhannes m zmoelnig zmoel...@iem.at Subject: [pix_video] osx Did you know that in gem 92, the device method of [pix_video] seems to have no effect ? I had to use two [pix_video] : one to force opening of the first camera, and one to get the other first remaining camera. It looks really weird. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] [pix_video] osx (fwd)
On Mon, 14 Feb 2011, chris clepper wrote: The messages are different on OSX because devices can and do have multiple inputs. Selecting a 'device' only is not enough information to tell the driver of something like a Blackmagic Intensity card so you need to add an 'input' message as well. ah, an input method is indeed defined in pix_videoDarwin.cpp, but it is not mentioned in pix_video-help.pd (of gem 92), and I have no hint that something is to be done. This behaviour of device is also contrary to [pix_video]'s construction-time behaviour of pick the first video stream we can find. I'm all in favour of a more manual camera control (so that the user chooses whether to open a camera at all), I'm just pointing out that device/input doesn't seem to be very consistent with [pix_video]'s defaults. BTW, which devices have several inputs on them, in a way that counts as input here (and not multiple devices) ? I'm curious. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] weirdeness
On Mon, 14 Feb 2011, IOhannes m zmoelnig wrote: ah, i think i start to understand. what you describe is definitely a bug, as in this case [pix_blabla] should fail to instantiate. i have rewritten the entire FreeFrame object a week or so ago, and this might have slipped in. Do you really think that it's a good idea to use a loader in this manner ? What is the possibility of nameclashes here ? ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] [pix_video] osx (fwd)
Many video capture devices have multiple physical inputs and some manufacturers use and input to set things like PAL/NTSC or colorspace or even resolution. The only way to really figure it out is with the 'dialog' window. It is kind of a pain to configure certain devices and some of the pix_videoDarwin code contains workarounds so I could do plug and play installations all over the world. I thought I added this to a help file long ago in a Mac specific subpatch. Maybe not. On Mon, Feb 14, 2011 at 12:56 PM, Mathieu Bouchard ma...@artengine.cawrote: On Mon, 14 Feb 2011, chris clepper wrote: The messages are different on OSX because devices can and do have multiple inputs. Selecting a 'device' only is not enough information to tell the driver of something like a Blackmagic Intensity card so you need to add an 'input' message as well. ah, an input method is indeed defined in pix_videoDarwin.cpp, but it is not mentioned in pix_video-help.pd (of gem 92), and I have no hint that something is to be done. This behaviour of device is also contrary to [pix_video]'s construction-time behaviour of pick the first video stream we can find. I'm all in favour of a more manual camera control (so that the user chooses whether to open a camera at all), I'm just pointing out that device/input doesn't seem to be very consistent with [pix_video]'s defaults. BTW, which devices have several inputs on them, in a way that counts as input here (and not multiple devices) ? I'm curious. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Re: [GEM-dev] weirdeness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/14/2011 06:58 PM, Mathieu Bouchard wrote: Do you really think that it's a good idea to use a loader in this manner ? yes. the idea is to make 3rd party plugins integrate seamlessly into Gem. What is the possibility of nameclashes here ? obviously it's there. e.g. there is a frei0r plugin called multiply, which could be accessed as [pix_multiply]. since [pix_multiply] is already built into Gem, you will never get the frei0r plugin this way, you have to explicitely use [pix_frei0r multiply] (btw, [pix_frei0r multiply] won't do either, simply because this plugin is a mixer, which is currently unsupported by Gem's frei0r implementation) fgmadr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1ZfSsACgkQkX2Xpv6ydvT9MQCeOL1G4qrIspoYoGNt6yO/buXl eu8AoI0Zkssel5dVMk98EGsxY3CbFZYH =S1HC -END PGP SIGNATURE- ___ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
