Pd-dev April 2008

pd-dev@lists.iem.at

24 participants
178 discussions

[ pure-data-Patches-1945042 ] [avg~] and [tavg~] from zexy broken in pd-ext
by SourceForge.net 17 Apr '08

17 Apr '08

Patches item #1945042, was opened at 2008-04-17 15:29 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=1945042&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roman Haefeli (reduzent) Assigned to: Nobody/Anonymous (nobody) Summary: [avg~] and [tavg~] from zexy broken in pd-ext Initial Comment: my test-patch: [avg~] | [print] doesn't print anything at all, even if audio is turned on or a non-zero signal is sent (e.g. [1 ( - [sig~] ) the same goes for [tavg~] i tested with pd-extended-0.40.3-20080308 on ubuntu dapper. ---------------------- the same behaviour i get with a current checkout of zexy from pd-svn, when i use the pd-extended makefile and compile zexy like this: cd pd-svn/externals make zexy -------------------------- [avg~] and [tavg~] work perfectly, if i compile them with the original makefile: cd pd-svn/externals/zexy/src ./configure make the resulting zexy.pd_linux _doesn't have his bug --------------------- -> the problem seems to be related to how zexy is compiled and not to the source of avg~ or tavg~. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1945042&group_…

1 0

pd external memory weirdness
by tim redfern 17 Apr '08

17 Apr '08

Hi I don't know if this the right place to post a question/plea for help but, I'm trying to write an external, that uses a pthread to do some speech synthesis without interrupting pd audio. I'm getting a very strange problem.. its leaking memory when invoked within the thread. After further investigation, I find that even a simple malloc/free is leaking all the memory it's allocating, even when called in the main pd thread, if there is another thread being created- its as if the act of making a new thread completely confuses malloc. Any thoughts, would this be something to do with pd or with the c library (glibc/ubuntu)? Thanks Tim

3 5

[ pure-data-Patches-1943614 ] speed up 'graph on parent'
by SourceForge.net 17 Apr '08

17 Apr '08

Patches item #1943614, was opened at 2008-04-16 06:25 Message generated for change (Comment added) made by jleben You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1943614&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-dev Group: feature Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jakob Leben (jleben) Assigned to: Nobody/Anonymous (nobody) Summary: speed up 'graph on parent' Initial Comment: Here is the update of my patch filed as 1943301 (move instead of draw when 'graphed on parent') - now made with diff -uwB ;) I fixed both of the bugs mentioned when I posted the first version of this patch. I noticed that one of them, namely the name of garray missing when array is created was a general bug and not produced by my code. This is now solved also, for the good of the pd community! I also added iemgui_graph function which now all iemgui objects call as their graph_fn function and it in turn calls object's x_gui.x_draw function. This allows for graph_displace to make generic calls to graph_fn functions of all of it's children. I would also like to point out that this patch only offers the possibility to use Tk command move for moving graphics of objects which are 'graphed on parent'. To add graph_fn functions to all the pd-vanilla objects I simply copied the code they use to draw themselves when being displaced, and currently many of them actually redraw themselves instead of just move. I paid attention that garray's graphics are really moved though, because to speed up array drawing was the main objective of writing this patch. One problem I wish to point at is: if an object uses iemgui_displace function (and it holds the same now for new iemgui_graph function) it actually loses possibility to easily use Tk move command, because iemgui functions don't pass the dx and dy arguments to local object's functions they call for drawing. Thus using iemgui_displace and iemgui_graph makes it even less convenient and effective. I think iemgui functions should do more to make writing of gui externals easy. ---------------------------------------------------------------------- >Comment By: Jakob Leben (jleben) Date: 2008-04-17 06:54 Message: Logged In: YES user_id=2064182 Originator: YES File Added: pd-0.41-4.leben4-garrayonly.patch ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-17 06:53 Message: Logged In: YES user_id=2064182 Originator: YES Fixed: wrong drawing of nested graphs-on-parent. File Added: pd-0.41-4.leben4.patch ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-17 04:13 Message: Logged In: YES user_id=2064182 Originator: YES File Added: pd-0.41-4-leben3.patch ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-17 04:12 Message: Logged In: YES user_id=2064182 Originator: YES New fix to the patch: changing plotting style for arrays didn't work right with the patch A thought: with this patch, redrawing the array is reduced to one time only after changes on the array dialog are applied. I also tweaked some functions in g_array.c so that they produce as little redrawings as possible. However, both garray_resize and garray_redraw produce redrawing and they are both "public" functions (in m_pd.h). This behaviour seems logical, but for example soundfiler object uses them both when reading a file into the array, so that the array gets redrawn twice, which is not good according to how CPU demanding is the plotting of arrays currently. I have no ideas how to solve this. File Added: pd-0.41-4-leben3-garrayonly.patch ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-16 20:18 Message: Logged In: YES user_id=2064182 Originator: YES File Added: pd-0.41-4-leben-garrayonly.patch ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-16 20:17 Message: Logged In: YES user_id=2064182 Originator: YES NEW FIXES: - displacing a graph on parent when it has it's window open moves graphical content inside this window. - displacing nested graphs on parent doesn't work (crash) I realized that there IS quite a lot of externals that use widget behaviors, so I also made another patch witch only fixes slow displacing of arrays and doesn't bring new widgetbehavior. This one can safely be used with pd-extended. File Added: pd-0.41-4-leben.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1943614&group_…

1 0

[ pure-data-Patches-1943614 ] speed up 'graph on parent'
by SourceForge.net 17 Apr '08

17 Apr '08

Patches item #1943614, was opened at 2008-04-16 06:25 Message generated for change (Comment added) made by jleben You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1943614&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-dev Group: feature Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jakob Leben (jleben) Assigned to: Nobody/Anonymous (nobody) Summary: speed up 'graph on parent' Initial Comment: Here is the update of my patch filed as 1943301 (move instead of draw when 'graphed on parent') - now made with diff -uwB ;) I fixed both of the bugs mentioned when I posted the first version of this patch. I noticed that one of them, namely the name of garray missing when array is created was a general bug and not produced by my code. This is now solved also, for the good of the pd community! I also added iemgui_graph function which now all iemgui objects call as their graph_fn function and it in turn calls object's x_gui.x_draw function. This allows for graph_displace to make generic calls to graph_fn functions of all of it's children. I would also like to point out that this patch only offers the possibility to use Tk command move for moving graphics of objects which are 'graphed on parent'. To add graph_fn functions to all the pd-vanilla objects I simply copied the code they use to draw themselves when being displaced, and currently many of them actually redraw themselves instead of just move. I paid attention that garray's graphics are really moved though, because to speed up array drawing was the main objective of writing this patch. One problem I wish to point at is: if an object uses iemgui_displace function (and it holds the same now for new iemgui_graph function) it actually loses possibility to easily use Tk move command, because iemgui functions don't pass the dx and dy arguments to local object's functions they call for drawing. Thus using iemgui_displace and iemgui_graph makes it even less convenient and effective. I think iemgui functions should do more to make writing of gui externals easy. ---------------------------------------------------------------------- >Comment By: Jakob Leben (jleben) Date: 2008-04-17 06:53 Message: Logged In: YES user_id=2064182 Originator: YES Fixed: wrong drawing of nested graphs-on-parent. File Added: pd-0.41-4.leben4.patch ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-17 04:13 Message: Logged In: YES user_id=2064182 Originator: YES File Added: pd-0.41-4-leben3.patch ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-17 04:12 Message: Logged In: YES user_id=2064182 Originator: YES New fix to the patch: changing plotting style for arrays didn't work right with the patch A thought: with this patch, redrawing the array is reduced to one time only after changes on the array dialog are applied. I also tweaked some functions in g_array.c so that they produce as little redrawings as possible. However, both garray_resize and garray_redraw produce redrawing and they are both "public" functions (in m_pd.h). This behaviour seems logical, but for example soundfiler object uses them both when reading a file into the array, so that the array gets redrawn twice, which is not good according to how CPU demanding is the plotting of arrays currently. I have no ideas how to solve this. File Added: pd-0.41-4-leben3-garrayonly.patch ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-16 20:18 Message: Logged In: YES user_id=2064182 Originator: YES File Added: pd-0.41-4-leben-garrayonly.patch ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-16 20:17 Message: Logged In: YES user_id=2064182 Originator: YES NEW FIXES: - displacing a graph on parent when it has it's window open moves graphical content inside this window. - displacing nested graphs on parent doesn't work (crash) I realized that there IS quite a lot of externals that use widget behaviors, so I also made another patch witch only fixes slow displacing of arrays and doesn't bring new widgetbehavior. This one can safely be used with pd-extended. File Added: pd-0.41-4-leben.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1943614&group_…

1 0

[ pure-data-Patches-1943614 ] speed up 'graph on parent'
by SourceForge.net 17 Apr '08

17 Apr '08

Patches item #1943614, was opened at 2008-04-16 06:25 Message generated for change (Comment added) made by jleben You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1943614&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-dev Group: feature Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jakob Leben (jleben) Assigned to: Nobody/Anonymous (nobody) Summary: speed up 'graph on parent' Initial Comment: Here is the update of my patch filed as 1943301 (move instead of draw when 'graphed on parent') - now made with diff -uwB ;) I fixed both of the bugs mentioned when I posted the first version of this patch. I noticed that one of them, namely the name of garray missing when array is created was a general bug and not produced by my code. This is now solved also, for the good of the pd community! I also added iemgui_graph function which now all iemgui objects call as their graph_fn function and it in turn calls object's x_gui.x_draw function. This allows for graph_displace to make generic calls to graph_fn functions of all of it's children. I would also like to point out that this patch only offers the possibility to use Tk command move for moving graphics of objects which are 'graphed on parent'. To add graph_fn functions to all the pd-vanilla objects I simply copied the code they use to draw themselves when being displaced, and currently many of them actually redraw themselves instead of just move. I paid attention that garray's graphics are really moved though, because to speed up array drawing was the main objective of writing this patch. One problem I wish to point at is: if an object uses iemgui_displace function (and it holds the same now for new iemgui_graph function) it actually loses possibility to easily use Tk move command, because iemgui functions don't pass the dx and dy arguments to local object's functions they call for drawing. Thus using iemgui_displace and iemgui_graph makes it even less convenient and effective. I think iemgui functions should do more to make writing of gui externals easy. ---------------------------------------------------------------------- >Comment By: Jakob Leben (jleben) Date: 2008-04-17 04:13 Message: Logged In: YES user_id=2064182 Originator: YES File Added: pd-0.41-4-leben3.patch ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-17 04:12 Message: Logged In: YES user_id=2064182 Originator: YES New fix to the patch: changing plotting style for arrays didn't work right with the patch A thought: with this patch, redrawing the array is reduced to one time only after changes on the array dialog are applied. I also tweaked some functions in g_array.c so that they produce as little redrawings as possible. However, both garray_resize and garray_redraw produce redrawing and they are both "public" functions (in m_pd.h). This behaviour seems logical, but for example soundfiler object uses them both when reading a file into the array, so that the array gets redrawn twice, which is not good according to how CPU demanding is the plotting of arrays currently. I have no ideas how to solve this. File Added: pd-0.41-4-leben3-garrayonly.patch ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-16 20:18 Message: Logged In: YES user_id=2064182 Originator: YES File Added: pd-0.41-4-leben-garrayonly.patch ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-16 20:17 Message: Logged In: YES user_id=2064182 Originator: YES NEW FIXES: - displacing a graph on parent when it has it's window open moves graphical content inside this window. - displacing nested graphs on parent doesn't work (crash) I realized that there IS quite a lot of externals that use widget behaviors, so I also made another patch witch only fixes slow displacing of arrays and doesn't bring new widgetbehavior. This one can safely be used with pd-extended. File Added: pd-0.41-4-leben.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1943614&group_…

1 0

[ pure-data-Patches-1943614 ] speed up 'graph on parent'
by SourceForge.net 17 Apr '08

17 Apr '08

Patches item #1943614, was opened at 2008-04-16 06:25 Message generated for change (Comment added) made by jleben You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1943614&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-dev Group: feature Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jakob Leben (jleben) Assigned to: Nobody/Anonymous (nobody) Summary: speed up 'graph on parent' Initial Comment: Here is the update of my patch filed as 1943301 (move instead of draw when 'graphed on parent') - now made with diff -uwB ;) I fixed both of the bugs mentioned when I posted the first version of this patch. I noticed that one of them, namely the name of garray missing when array is created was a general bug and not produced by my code. This is now solved also, for the good of the pd community! I also added iemgui_graph function which now all iemgui objects call as their graph_fn function and it in turn calls object's x_gui.x_draw function. This allows for graph_displace to make generic calls to graph_fn functions of all of it's children. I would also like to point out that this patch only offers the possibility to use Tk command move for moving graphics of objects which are 'graphed on parent'. To add graph_fn functions to all the pd-vanilla objects I simply copied the code they use to draw themselves when being displaced, and currently many of them actually redraw themselves instead of just move. I paid attention that garray's graphics are really moved though, because to speed up array drawing was the main objective of writing this patch. One problem I wish to point at is: if an object uses iemgui_displace function (and it holds the same now for new iemgui_graph function) it actually loses possibility to easily use Tk move command, because iemgui functions don't pass the dx and dy arguments to local object's functions they call for drawing. Thus using iemgui_displace and iemgui_graph makes it even less convenient and effective. I think iemgui functions should do more to make writing of gui externals easy. ---------------------------------------------------------------------- >Comment By: Jakob Leben (jleben) Date: 2008-04-17 04:12 Message: Logged In: YES user_id=2064182 Originator: YES New fix to the patch: changing plotting style for arrays didn't work right with the patch A thought: with this patch, redrawing the array is reduced to one time only after changes on the array dialog are applied. I also tweaked some functions in g_array.c so that they produce as little redrawings as possible. However, both garray_resize and garray_redraw produce redrawing and they are both "public" functions (in m_pd.h). This behaviour seems logical, but for example soundfiler object uses them both when reading a file into the array, so that the array gets redrawn twice, which is not good according to how CPU demanding is the plotting of arrays currently. I have no ideas how to solve this. File Added: pd-0.41-4-leben3-garrayonly.patch ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-16 20:18 Message: Logged In: YES user_id=2064182 Originator: YES File Added: pd-0.41-4-leben-garrayonly.patch ---------------------------------------------------------------------- Comment By: Jakob Leben (jleben) Date: 2008-04-16 20:17 Message: Logged In: YES user_id=2064182 Originator: YES NEW FIXES: - displacing a graph on parent when it has it's window open moves graphical content inside this window. - displacing nested graphs on parent doesn't work (crash) I realized that there IS quite a lot of externals that use widget behaviors, so I also made another patch witch only fixes slow displacing of arrays and doesn't bring new widgetbehavior. This one can safely be used with pd-extended. File Added: pd-0.41-4-leben.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1943614&group_…

1 0

[ pure-data-Bugs-1944415 ] plugin~ help crashes Pd-extended on Mac OS X
by SourceForge.net 17 Apr '08

17 Apr '08

Bugs item #1944415, was opened at 2008-04-16 18:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1944415&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: externals Group: v0.40.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody) Summary: plugin~ help crashes Pd-extended on Mac OS X Initial Comment: In the process of trying the help patch from #1944380, I just foudn another bug: the plugin~ help patch crashes Pd on Mac OS X 10.4.11/Intel using Pd-0.40.3-extended-20080403. I am guessing that this is related to the plugin files it is trying to load ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1944415&group_…

1 0

build error
by marius schebella 16 Apr '08

16 Apr '08

hi, trying to build an intel build of pd-extended and get an error for toxy, don't know what is wrong. thanks, marius. gcc -Wall -W -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -march=pentium4 -msse2 -mfpmath=sse -ftree-vectorize -ftree-vectorizer-verbose=2 -DUNIX -DMACOSX -I . -I ../../../pd/src -I ../shared -c -o widgettype.o widgettype.c In file included from widgettype.c:16: setup.wiq:2: error: Â‘eÂ’ undeclared here (not in a function) setup.wiq:2: error: syntax error before Â‘packageÂ’ In file included from widgettype.c:16: setup.wiq:2:29: error: too many decimal points in number setup.wiq:4:3: error: invalid preprocessing directive #LATER setup.wiq:5:3: error: invalid preprocessing directive #glue setup.wiq:6:3: error: invalid preprocessing directive #LATER setup.wiq:7:3: error: invalid preprocessing directive #LATER setup.wiq:8:3: error: invalid preprocessing directive #way setup.wiq:9:3: error: invalid preprocessing directive #right setup.wiq:11:3: error: invalid preprocessing directive #LATER setup.wiq:14:3: error: invalid preprocessing directive #FIXME setup.wiq:18: error: syntax error before Â‘{Â’ token setup.wiq:23:3: error: invalid preprocessing directive #valid setup.wiq:32:3: error: invalid preprocessing directive #FIXME setup.wiq:33:3: error: invalid preprocessing directive #In setup.wiq:34:3: error: invalid preprocessing directive #try setup.wiq:39:3: error: invalid preprocessing directive #FIXME setup.wiq:40:7: error: invalid preprocessing directive #pd setup.wiq:73:3: error: invalid preprocessing directive #LATER setup.wiq:80: error: syntax error before Â‘{Â’ token setup.wiq:99: error: syntax error before Â‘{Â’ token setup.wiq:106:3: error: invalid preprocessing directive #LATER setup.wiq:111: error: stray Â‘\Â’ in program setup.wiq:131:3: error: invalid preprocessing directive #FIXME setup.wiq:133:3: error: invalid preprocessing directive #FIXME setup.wiq:148:3: error: invalid preprocessing directive #puts setup.wiq:150:7: error: invalid preprocessing directive #puts setup.wiq:154: error: Â‘catchÂ’ undeclared here (not in a function) setup.wiq:154: error: syntax error before Â‘{Â’ token setup.wiq:175:3: error: invalid preprocessing directive #puts setup.wiq:187: error: syntax error before Â‘&Â’ token setup.wiq:187: error: Â‘concatÂ’ undeclared here (not in a function) setup.wiq:187: error: syntax error before Â‘tclÂ’ setup.wiq:188: error: stray Â‘\Â’ in program setup.wiq:192:3: error: invalid preprocessing directive #empirically setup.wiq:193:3: error: invalid preprocessing directive #better setup.wiq:196: error: stray Â‘\Â’ in program setup.wiq:202: error: stray Â‘\Â’ in program setup.wiq:207:3: error: invalid preprocessing directive #pdtk_canvas_mouseup setup.wiq:214: error: stray Â‘\Â’ in program setup.wiq:243:3: error: invalid preprocessing directive #undo setup.wiq:248:3: error: invalid preprocessing directive #to setup.wiq:273:3: error: invalid preprocessing directive #standard setup.wiq:275:3: error: invalid preprocessing directive #FIXME setup.wiq:278: error: stray Â‘\Â’ in program setup.wiq:290: error: stray Â‘\Â’ in program setup.wiq:292: error: stray Â‘\Â’ in program setup.wiq:298:3: error: invalid preprocessing directive #puts setup.wiq:299: error: syntax error before Â‘{Â’ token setup.wiq:315:3: error: invalid preprocessing directive #FIXME setup.wiq:318:2: error: invalid preprocessing directive #> setup.wiq:319:2: error: invalid preprocessing directive #. setup.wiq:320:2: error: invalid preprocessing directive #. setup.wiq:321:2: error: invalid preprocessing directive #. setup.wiq:323:2: error: invalid preprocessing directive #> setup.wiq:324:2: error: invalid preprocessing directive #. setup.wiq:325:2: error: invalid preprocessing directive #. setup.wiq:326:2: error: invalid preprocessing directive #. setup.wiq:327:2: error: invalid preprocessing directive #. setup.wiq:329:2: error: invalid preprocessing directive #> setup.wiq:330:2: error: invalid preprocessing directive #. setup.wiq:331:2: error: invalid preprocessing directive #. setup.wiq:333:2: error: invalid preprocessing directive #@ setup.wiq:336:2: error: invalid preprocessing directive #> setup.wiq:337:2: error: invalid preprocessing directive #. setup.wiq:338:2: error: invalid preprocessing directive #. setup.wiq:339:2: error: invalid preprocessing directive #. setup.wiq:340:2: error: invalid preprocessing directive #. setup.wiq:341:2: error: invalid preprocessing directive #. setup.wiq:342:2: error: invalid preprocessing directive #. setup.wiq:344:2: error: invalid preprocessing directive #@ setup.wiq:345: error: stray Â‘#Â’ in program setup.wiq:345: error: stray Â‘#Â’ in program make[3]: *** [widgettype.o] Error 1 make[2]: *** [toxy_install] Error 2 make[1]: *** [externals_install] Error 2 make: *** [extended_install] Error 2

6 21

[ pure-data-Bugs-1944380 ] fixed help patch for plugin~
by SourceForge.net 16 Apr '08

16 Apr '08

Bugs item #1944380, was opened at 2008-04-16 14:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1944380&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: fixed help patch for plugin~ Initial Comment: The plugin~ object was incorrectly using a [print< message. By reading the source, I saw that it should have been using an [info< message. I changed this and added [print] objects so that the output in response to the info messages can be seen. I added attribution of this fix to the file, which you can feel free to remove if it is inappropriate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1944380&group_…

1 0

[ pure-data-Patches-1943614 ] speed up 'graph on parent'
by SourceForge.net 16 Apr '08

16 Apr '08

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
18
Older →

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