Pd-dev April 2008

pd-dev@lists.iem.at

24 participants
178 discussions

profiling the Tcl<->Pd connection
by Hans-Christoph Steiner 19 May '08

19 May '08

Now that I have discovered this bytecode caching feature, I am curious if the changes I made have made any performance differences. Also, matju mentioned that the bytecode caching probably works better if reusing procs, so it could make sense to have sys_vgui calls use Tcl procs, so that the bytecode gets reused. I was also thinking that perhaps sys_vgui communications could use Tcl_Obj references instead of sending whole lines of Tcl, but that might get overly complicated. .hc ------------------------------------------------------------------------ ---- http://at.or.at/hans/

5 10

[ pure-data-Bugs-1830771 ] Pd extended starts animation effect on XP
by SourceForge.net 30 Apr '08

30 Apr '08

Bugs item #1830771, was opened at 2007-11-13 01:19 Message generated for change (Settings changed) made by jmmmp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1830771&group_… 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: pd-extended >Group: v0.40.2 Status: Open Resolution: Works For Me Priority: 5 Private: No Submitted By: João Miguel Pais (jmmmp) Assigned to: Hans-Christoph Steiner (eighthave) Summary: Pd extended starts animation effect on XP Initial Comment: This actually always happened with Pd-ext as far as I remember. Each time I start Pd-ext, the Einblendeffekt (animation? can't find a translation) gets activated. This effect is what makes the windows "travel" when they're being minimized or maximized. You find it in - right-click on the desktop - properties - 4th Tab [Darstellung], display?? - effects - 1st checkbox, [use the next effects for menus and quickinfos] - Einblendeffekt [the menu names were translated by me from german, they might not be correct] ---------------------------------------------------------------------- >Comment By: João Miguel Pais (jmmmp) Date: 2008-04-30 15:46 Message: Logged In: YES user_id=1523458 Originator: YES It works fine, I just tried it and nothing wrong happened. ---------------------------------------------------------------------- Comment By: João Miguel Pais (jmmmp) Date: 2008-04-28 12:22 Message: Logged In: YES user_id=1523458 Originator: YES Is .43-ext already final? I tried it a couple weeks ago, and it was buggy. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-28 07:00 Message: Logged In: YES user_id=27104 Originator: NO I can't reproduce this on English Windows XP SP2 with all updates using Pd-0.40.3-extended-20080427. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1830771&group_…

1 0

[ pure-data-Bugs-1499215 ] openpanel crash
by SourceForge.net 30 Apr '08

30 Apr '08

Bugs item #1499215, was opened at 2006-06-02 02:11 Message generated for change (Comment added) made by jmmmp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1499215&group_… 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: puredata >Group: v0.40.2 >Status: Open Resolution: None Priority: 5 Private: No Submitted By: João Miguel Pais (jmmmp) Assigned to: Nobody/Anonymous (nobody) Summary: openpanel crash Initial Comment: when openpanel is clicked and the selection window comes up, pd crashes. this doesn't happen all the time, but will happen for sure if f.e. something with openpanel has been done before. XP, 0.93t3 ---------------------------------------------------------------------- >Comment By: João Miguel Pais (jmmmp) Date: 2008-04-30 15:44 Message: Logged In: YES user_id=1523458 Originator: YES I just installed and tried out the latest build of .43 ext, and it seems to work well. I'm not on pd too much these days, but the test I've made would have crashed earlier versions, I think. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-28 23:18 Message: Logged In: YES user_id=27104 Originator: NO is this still an issue with the recent nightly builds of Pd-extended or Pd-0.41-4? Tcl/Tk has been upgraded on Windows to Tcl/Tk 8.4.18. I think Miller is still using an old build. ---------------------------------------------------------------------- Comment By: christopher clepper (cclepper) Date: 2007-01-05 17:16 Message: Logged In: YES user_id=663212 Originator: NO Yes, the panel is still open when Pd exits. What Tcl/Tk version are you using when testing? ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-01-05 17:00 Message: Logged In: YES user_id=27104 Originator: NO So does the crash happen with the open panel is still open? If so, that sounds like a Tcl/Tk issue maybe. I know that there are a number of updates available. ---------------------------------------------------------------------- Comment By: christopher clepper (cclepper) Date: 2007-01-05 16:41 Message: Logged In: YES user_id=663212 Originator: NO I have this happen quite a lot on my Windows development machine. The way I reproduced it involved opening a dialog and then the next open dialog browsing my desktop for a few seconds. Pd would exit immediately with a 1. The debugger never caught anything either. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-01-05 01:44 Message: Logged In: YES user_id=27104 Originator: NO I can't reproduce this on Pd-0.39.2-extended-test7. Is there any more info? ---------------------------------------------------------------------- Comment By: João Miguel Pais (jmmmp) Date: 2006-08-07 18:15 Message: Logged In: YES user_id=1523458 this has been happening a lot in my computer lately. I guess there's a conflict between openpanel and window's commentaries to files. my mouse has automatic selection (follows the pointer, I only have to click once to open a file). when I use openpanel after the 1st time, if I'm not fast selecting a file it *will almost for sure* crash pd. no example patch necessary, just any patch with openpanel. apparently the chances increase if a patch with GOPs was opened (it's only a hunch). ---------------------------------------------------------------------- Comment By: João Miguel Pais (jmmmp) Date: 2006-07-07 13:35 Message: Logged In: YES user_id=1523458 This is the only information I can give, because the behaviour is erratic, and I can't establish a pattern. the only thing I know for sure is that it doesn't happen on the first time. example patch isn't necessary, just banging any openpanel - it's a general behaviour, not specific to any singular patch. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-07-07 02:22 Message: Logged In: YES user_id=27104 This is a pretty vague bug report. Any more info? Example patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1499215&group_…

1 0

[ pure-data-Bugs-1953770 ] Path... pref pane crashes with more than 33 elements
by SourceForge.net 30 Apr '08

30 Apr '08

Bugs item #1953770, was opened at 2008-04-29 02:17 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1953770&group_… 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: puredata Group: None Status: Open >Resolution: Duplicate Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody) Summary: Path... pref pane crashes with more than 33 elements Initial Comment: The Path... preferences pane causes Pd to crash if it has too many elements loaded in it. It seems to happen around 42 path elements. ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2008-04-30 09:17 Message: Logged In: YES user_id=564396 Originator: NO can you confirm that this is a duplication of bug #1936531 ? http://sourceforge.net/tracker/index.php?func=detail&aid=1936531&group_id=5… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1953770&group_…

1 0

changing glob_setfilename() to handle spaces in the dirname
by Hans-Christoph Steiner 29 Apr '08

29 Apr '08

Currently, the function glob_setfilename() is defined in g_canvas.c like this: void glob_setfilename(void *dummy, t_symbol *filesym, t_symbol *dirsym) That means when you send names from tcl using [pd filename], any spaces in the directory name get dropped. I propose adding this to g_canvas.c and then using that for the 'pd filename' callback instead. glob_setfilename() would then be left since it is used interally and in some extenrals: void glob_setfilename_gimme(void *dummy, t_symbol *s, int argc, t_atom *argv) How does that sound? Any better approach? .hc ------------------------------------------------------------------------ ---- "[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.

3 6

[ pure-data-Patches-1953853 ] fix for the closed bug 1795369 (red border GOP)
by SourceForge.net 29 Apr '08

29 Apr '08

Patches item #1953853, was opened at 2008-04-29 05:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1953853&group_… 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: puredata Group: bugfix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jakob Leben (jleben) Assigned to: Nobody/Anonymous (nobody) Summary: fix for the closed bug 1795369 (red border GOP) Initial Comment: This patch fixes the following bug: The "graph on parent" red rectangle is drawn on the parent patch when an object is created in a subpatch by sending it a message after the subpatch has been set to GOP but it's window has been closed before any objects had been created in it. This is a patch against pd-0.41-4. --- pd2patch-orig/g_graph.c 2008-03-15 01:03:00.000000000 +0100 +++ pd2patch-leben/g_graph.c 2008-04-29 01:53:17.000000000 +0200 @@ -43,7 +43,7 @@ && pd_checkobject(&y->g_pd)) { x->gl_goprect = 1; - canvas_drawredrect(x, 1); + if(x->gl_havewindow) canvas_drawredrect(x, 1); } if (glist_isvisible(x)) gobj_vis(y, x, 1); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1953853&group_…

1 0

[ pure-data-Patches-1953772 ] fix bug 1795369 (red border GOP)
by SourceForge.net 29 Apr '08

29 Apr '08

Patches item #1953772, was opened at 2008-04-28 20:18 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1953772&group_… 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: puredata Group: bugfix >Status: Deleted >Resolution: Duplicate Priority: 5 Private: No Submitted By: Jakob Leben (jleben) Assigned to: Nobody/Anonymous (nobody) Summary: fix bug 1795369 (red border GOP) Initial Comment: This fixes the bug: Red rectangle is drawn on the parent patch when creating the first object in a GOP subpatch without it's window open by sending a message to the subpatch. This is a patch against pd-0.41-4. --- pd2patch-orig/g_graph.c 2008-03-15 01:03:00.000000000 +0100 +++ pd2patch-leben/g_graph.c 2008-04-29 01:53:17.000000000 +0200 @@ -43,7 +43,7 @@ && pd_checkobject(&y->g_pd)) { x->gl_goprect = 1; - canvas_drawredrect(x, 1); + if(x->gl_havewindow) canvas_drawredrect(x, 1); } if (glist_isvisible(x)) gobj_vis(y, x, 1); ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-28 21:05 Message: Logged In: YES user_id=27104 Originator: NO this is a duplicate, please post in the original: http://sourceforge.net/tracker/index.php?func=detail&aid=1351274&group_id=5… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1953772&group_…

1 0

[ pure-data-Bugs-1795369 ] red border GOP
by SourceForge.net 29 Apr '08

29 Apr '08

Bugs item #1795369, was opened at 2007-09-14 23:47 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1795369&group_… 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: puredata Group: None >Status: Closed Resolution: Duplicate Priority: 5 Private: No Submitted By: marius schebella (mariusschebella) Assigned to: Nobody/Anonymous (nobody) Summary: red border GOP Initial Comment: hey, when I have a subpatch that contains no element in it, but is a GOP, then I don't see the red GOP border. that does not seem to be a problem. BUT... when I use this empty subpatch and create an object in it via message command, then that red border suddenly is visible in the parent patch. see attached file. marius. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-28 21:04 Message: Logged In: YES user_id=27104 Originator: NO this is a duplicate, please do not post here, instead use this one: http://sourceforge.net/tracker/index.php?func=detail&aid=1351274&group_id=5… ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-28 20:29 Message: Logged In: YES user_id=2064182 Originator: NO allright, the problem with red rectangle being drawn in a wrong situation was in glist_add (g_graph.c). I posted a patch: https://sourceforge.net/tracker/index.php?func=detail&aid=1953772&group_id=… For reasons I explained below I don't consider a bug the fact that red rectangle is not drawn immediately after a subpatch is created and set to GOP. I'm saying that because the bug no. 1351274 seems to still be open. ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-28 19:00 Message: Logged In: YES user_id=2064182 Originator: NO umm, sorry, that was graph_vis (g_graph.c) instead of garray_vis (g_array.c). ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-28 15:38 Message: Logged In: YES user_id=2064182 Originator: NO The reason, I think, why red border doesn't show up when no elements present is: The same GOP technique is used to show the contents of a subpatch that contains data structures - for example an audio array. In this case you really don't want the red border to be drawn over the graphical representation of data structures, do you? So, red border gets drawn only when there are elements which are at the same time not data structures. This I wouldn't consider a bug then. What's your opinion? Now, why it gets drawn when an object is created via message command: the red border gets drawn in the garray_vis function (g_array.c). This function apparently gets called every time an object is created, exactly because that's the point when the red border might need to be drawn. I think the reason why when you have the subpatch open the GOP on the parent patch is covered over with a grey square is just to avoid the problem of having to visualize GOP on the parent and the subpatch window at the same time but differently (for example: on the parent patch without the red border). But the code obviously doesn't handle the case when a GOP's window is closed and when you create an object it calls garray_vis which draws the red square. Therefore we should add some checking inside garray_vis. This is my idea. Maybe I'll try to solve the problem or I hope this text will be of help to whoever else. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-28 12:09 Message: Logged In: YES user_id=27104 Originator: NO Try this link: http://sourceforge.net/tracker/index.php?func=detail&aid=1351274&group_id=5… ---------------------------------------------------------------------- Comment By: marius schebella (mariusschebella) Date: 2008-04-28 11:19 Message: Logged In: YES user_id=1856112 Originator: YES it's the same, but #1351274 does not show up when I browse the bugs. wrong settings? strange. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-28 10:43 Message: Logged In: YES user_id=27104 Originator: NO This is the same as bug #1351274 ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-28 10:42 Message: Logged In: YES user_id=27104 Originator: NO This is the same as bug #1351274 http://sourceforge.net/tracker/index.php?func=browse&group_id=55736&atid=47… ---------------------------------------------------------------------- Comment By: stffn (stffn) Date: 2007-10-16 09:58 Message: Logged In: YES user_id=1658640 Originator: NO This seam very similar to the report #1351274 called "pd 0.39-1 GOP bounding box doesn't appear if no objects". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1795369&group_…

1 0

[ pure-data-Bugs-1795369 ] red border GOP
by SourceForge.net 29 Apr '08

29 Apr '08

Bugs item #1795369, was opened at 2007-09-14 23:47 Message generated for change (Settings changed) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1795369&group_… 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: puredata Group: None >Status: Open Resolution: Duplicate Priority: 5 Private: No Submitted By: marius schebella (mariusschebella) Assigned to: Nobody/Anonymous (nobody) Summary: red border GOP Initial Comment: hey, when I have a subpatch that contains no element in it, but is a GOP, then I don't see the red GOP border. that does not seem to be a problem. BUT... when I use this empty subpatch and create an object in it via message command, then that red border suddenly is visible in the parent patch. see attached file. marius. ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-28 20:29 Message: Logged In: YES user_id=2064182 Originator: NO allright, the problem with red rectangle being drawn in a wrong situation was in glist_add (g_graph.c). I posted a patch: https://sourceforge.net/tracker/index.php?func=detail&aid=1953772&group_id=… For reasons I explained below I don't consider a bug the fact that red rectangle is not drawn immediately after a subpatch is created and set to GOP. I'm saying that because the bug no. 1351274 seems to still be open. ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-28 19:00 Message: Logged In: YES user_id=2064182 Originator: NO umm, sorry, that was graph_vis (g_graph.c) instead of garray_vis (g_array.c). ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-28 15:38 Message: Logged In: YES user_id=2064182 Originator: NO The reason, I think, why red border doesn't show up when no elements present is: The same GOP technique is used to show the contents of a subpatch that contains data structures - for example an audio array. In this case you really don't want the red border to be drawn over the graphical representation of data structures, do you? So, red border gets drawn only when there are elements which are at the same time not data structures. This I wouldn't consider a bug then. What's your opinion? Now, why it gets drawn when an object is created via message command: the red border gets drawn in the garray_vis function (g_array.c). This function apparently gets called every time an object is created, exactly because that's the point when the red border might need to be drawn. I think the reason why when you have the subpatch open the GOP on the parent patch is covered over with a grey square is just to avoid the problem of having to visualize GOP on the parent and the subpatch window at the same time but differently (for example: on the parent patch without the red border). But the code obviously doesn't handle the case when a GOP's window is closed and when you create an object it calls garray_vis which draws the red square. Therefore we should add some checking inside garray_vis. This is my idea. Maybe I'll try to solve the problem or I hope this text will be of help to whoever else. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-28 12:09 Message: Logged In: YES user_id=27104 Originator: NO Try this link: http://sourceforge.net/tracker/index.php?func=detail&aid=1351274&group_id=5… ---------------------------------------------------------------------- Comment By: marius schebella (mariusschebella) Date: 2008-04-28 11:19 Message: Logged In: YES user_id=1856112 Originator: YES it's the same, but #1351274 does not show up when I browse the bugs. wrong settings? strange. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-28 10:43 Message: Logged In: YES user_id=27104 Originator: NO This is the same as bug #1351274 ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-28 10:42 Message: Logged In: YES user_id=27104 Originator: NO This is the same as bug #1351274 http://sourceforge.net/tracker/index.php?func=browse&group_id=55736&atid=47… ---------------------------------------------------------------------- Comment By: stffn (stffn) Date: 2007-10-16 09:58 Message: Logged In: YES user_id=1658640 Originator: NO This seam very similar to the report #1351274 called "pd 0.39-1 GOP bounding box doesn't appear if no objects". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1795369&group_…

1 0

[ pure-data-Bugs-1795369 ] red border GOP
by SourceForge.net 29 Apr '08

29 Apr '08

Bugs item #1795369, was opened at 2007-09-15 05:47 Message generated for change (Comment added) made by jleben You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1795369&group_… 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: puredata Group: None Status: Closed Resolution: Duplicate Priority: 5 Private: No Submitted By: marius schebella (mariusschebella) Assigned to: Nobody/Anonymous (nobody) Summary: red border GOP Initial Comment: hey, when I have a subpatch that contains no element in it, but is a GOP, then I don't see the red GOP border. that does not seem to be a problem. BUT... when I use this empty subpatch and create an object in it via message command, then that red border suddenly is visible in the parent patch. see attached file. marius. ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-29 02:29 Message: Logged In: YES user_id=2064182 Originator: NO allright, the problem with red rectangle being drawn in a wrong situation was in glist_add (g_graph.c). I posted a patch: https://sourceforge.net/tracker/index.php?func=detail&aid=1953772&group_id=… For reasons I explained below I don't consider a bug the fact that red rectangle is not drawn immediately after a subpatch is created and set to GOP. I'm saying that because the bug no. 1351274 seems to still be open. ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-29 01:00 Message: Logged In: YES user_id=2064182 Originator: NO umm, sorry, that was graph_vis (g_graph.c) instead of garray_vis (g_array.c). ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-28 21:38 Message: Logged In: YES user_id=2064182 Originator: NO The reason, I think, why red border doesn't show up when no elements present is: The same GOP technique is used to show the contents of a subpatch that contains data structures - for example an audio array. In this case you really don't want the red border to be drawn over the graphical representation of data structures, do you? So, red border gets drawn only when there are elements which are at the same time not data structures. This I wouldn't consider a bug then. What's your opinion? Now, why it gets drawn when an object is created via message command: the red border gets drawn in the garray_vis function (g_array.c). This function apparently gets called every time an object is created, exactly because that's the point when the red border might need to be drawn. I think the reason why when you have the subpatch open the GOP on the parent patch is covered over with a grey square is just to avoid the problem of having to visualize GOP on the parent and the subpatch window at the same time but differently (for example: on the parent patch without the red border). But the code obviously doesn't handle the case when a GOP's window is closed and when you create an object it calls garray_vis which draws the red square. Therefore we should add some checking inside garray_vis. This is my idea. Maybe I'll try to solve the problem or I hope this text will be of help to whoever else. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-28 18:09 Message: Logged In: YES user_id=27104 Originator: NO Try this link: http://sourceforge.net/tracker/index.php?func=detail&aid=1351274&group_id=5… ---------------------------------------------------------------------- Comment By: marius schebella (mariusschebella) Date: 2008-04-28 17:19 Message: Logged In: YES user_id=1856112 Originator: YES it's the same, but #1351274 does not show up when I browse the bugs. wrong settings? strange. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-28 16:43 Message: Logged In: YES user_id=27104 Originator: NO This is the same as bug #1351274 ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-28 16:42 Message: Logged In: YES user_id=27104 Originator: NO This is the same as bug #1351274 http://sourceforge.net/tracker/index.php?func=browse&group_id=55736&atid=47… ---------------------------------------------------------------------- Comment By: stffn (stffn) Date: 2007-10-16 15:58 Message: Logged In: YES user_id=1658640 Originator: NO This seam very similar to the report #1351274 called "pd 0.39-1 GOP bounding box doesn't appear if no objects". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1795369&group_…

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev April 2008