Bugs item #3177253, was opened at 2011-02-10 11:13 Message generated for change (Comment added) made by nusmuk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3177253...
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Pixes (pix_ objects) Group: None
Status: Open
Resolution: Fixed Priority: 7 Private: No Submitted By: Cyrille Henry (nusmuk) Assigned to: Nobody/Anonymous (nobody) Summary: pix_crop does not work anymore
Initial Comment: using pix_crop help patch, it did not crop anything. tested with Gem build from 7 feb 2011 it work great on an other computer with Gem from 24 Dec 2010.
both computer using ubuntu 10.04
----------------------------------------------------------------------
Comment By: Cyrille Henry (nusmuk)
Date: 2011-02-11 10:57
Message: thanks for the very fast fix.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-02-10 12:57
Message: fixed in rev3700.
thanks for the report.
----------------------------------------------------------------------
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3177253...
Comment By: Cyrille Henry (nusmuk)
Message: thanks for the very fast fix.
as you might have noticed i changed something in the core infrastructure of Gem, which should have been transparent. both the [pix_crop] and the [pix_data] bug were closely related to that.
there might be some more bugs caused by the change, so please report any weirdnesses as soon as you notice them.
fgamdsr IOhannes
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...
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?
cheers, C
Le 11/02/2011 12:10, IOhannes zmölnig a écrit :
Comment By: Cyrille Henry (nusmuk)
Message: thanks for the very fast fix.
as you might have noticed i changed something in the core infrastructure of Gem, which should have been transparent. both the [pix_crop] and the [pix_data] bug were closely related to that.
there might be some more bugs caused by the change, so please report any weirdnesses as soon as you notice them.
fgamdsr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-----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
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
-----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
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
Le 14/02/2011 12:53, cyrille henry a écrit :
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%
same patch, but removing the cube object gives no big difference. c
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-14 12:53, cyrille henry wrote:
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.
well, but at the expense of performance.
anyhow, i have changed the internals again to use integer keys rather than symbolic keys, which speeds things up again. it's still not as fast as it used to be, but at least we are getting there. please check if this is sufficient.
gmasdf IOhannes
hello,
if you send 0 to a gemhead, it will still emit gem_state 1 at every images. i assume this is a bug.
yes, performances are almost as it's used to be.
thanks a lot for this cyrille
Le 23/02/2011 18:14, IOhannes m zmoelnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-14 12:53, cyrille henry wrote:
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.
well, but at the expense of performance.
anyhow, i have changed the internals again to use integer keys rather than symbolic keys, which speeds things up again. it's still not as fast as it used to be, but at least we are getting there. please check if this is sufficient.
gmasdf IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1lQF0ACgkQkX2Xpv6ydvQrugCgp04RKZmXGu6TlXOCCumrTIB0 hOwAoIXKpqqs42k3ReJVPSY4RtiScpJT =/yse -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-23 18:51, cyrille henry wrote:
hello,
if you send 0 to a gemhead, it will still emit gem_state 1 at every images. i assume this is a bug.
it is. and fixed.
yes, performances are almost as it's used to be.
great.
fgamsdr IOhannes
Le 23/02/2011 19:18, IOhannes m zmoelnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-23 18:51, cyrille henry wrote:
hello,
if you send 0 to a gemhead, it will still emit gem_state 1 at every images. i assume this is a bug.
it is. and fixed.
thanks
yes, performances are almost as it's used to be.
great.
now, could you make it faster than it use to be? ;-)
c
fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1lT5EACgkQkX2Xpv6ydvRwtACfU2CHQ7iOJS4WiyLmIEBxpcxp YPIAoLxrYM+XHx6Lw+FSkkZTf5BySG3h =tzPK -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-----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
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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-14 12:44, cyrille henry wrote:
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.
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.
fgamdr IOhannes
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
-----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
On Mon, 14 Feb 2011, IOhannes m zmölnig wrote:
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]
also PdVjTools' [pix_preview] vs FreeFrame's [pix_preview]. I just saw this by trying to load PdVjTools' pix_preview-help.pd without compiling the actual external.
but I'm not looking into making a list, I'm looking into not causing nameclashes by importing names from people who have no idea about the existence of the [pix_...] namespace in Pd/Gem (because they don't use Pd, for example).
is it a good idea to have seamless integration ?
_______________________________________________________________________ | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-15 18:19, Mathieu Bouchard wrote:
also PdVjTools' [pix_preview] vs FreeFrame's [pix_preview]. I just saw this by trying to load PdVjTools' pix_preview-help.pd without compiling the actual external.
agreed. however, so far nobody complained yet :-) (well, you did, but i assume that this is more an academic complaint rather than a real-world problem)
it might be a good idea to let the user enable the loaders (right now they have no chance)
fgamsdr IOhannes
On Tue, 15 Feb 2011, IOhannes m zmoelnig wrote:
agreed. however, so far nobody complained yet :-) (well, you did, but i assume that this is more an academic complaint rather than a real-world problem)
Are you waiting for it to become a real-world problem ? :)
Then it'd be sort of too late.
_______________________________________________________________________ | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Tue, 15 Feb 2011, Mathieu Bouchard wrote:
On Mon, 14 Feb 2011, IOhannes m zmölnig wrote: also PdVjTools' [pix_preview] vs FreeFrame's [pix_preview]. I just saw this by trying to load PdVjTools' pix_preview-help.pd without compiling the actual external.
Ah, this was actually just the FreeFrame loader taking any name like [pix_whatever_unlikely_name_you_may_write_in_an_objectbox] and considering it as a FreeFrame thing. It wasn't an actual name clash. I don't know the FreeFrame plugins nor what names they might have.
(After a SVN update, this behaviour is gone.)
_______________________________________________________________________ | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-17 05:05, Mathieu Bouchard wrote:
On Tue, 15 Feb 2011, Mathieu Bouchard wrote:
On Mon, 14 Feb 2011, IOhannes m zmölnig wrote: also PdVjTools' [pix_preview] vs FreeFrame's [pix_preview]. I just saw this by trying to load PdVjTools' pix_preview-help.pd without compiling the actual external.
Ah, this was actually just the FreeFrame loader taking any name like [pix_whatever_unlikely_name_you_may_write_in_an_objectbox] and considering it as a FreeFrame thing. It wasn't an actual name clash. I don't know the FreeFrame plugins nor what names they might have.
(After a SVN update, this behaviour is gone.)
yep that was a bug.
but obviously, if _there_ was an FF or frei0r plugin named "preview", it would nameclash.
fgamsdr IOhannes
-
cyrille henry -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
IOhannes zmölnig
-
Jack -
Mathieu Bouchard -
SourceForge.net