Pd-dev August 2011

pd-dev@lists.iem.at

13 participants
59 discussions

[ pure-data-Patches-3400300 ] move cord drawing from pd to Tcl procs in pd-gui
by SourceForge.net 01 Sep '11

01 Sep '11

Patches item #3400300, was opened at 2011-08-29 15:08 Message generated for change (Comment added) made by jancsika1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3400300&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: feature Status: Open Resolution: None Priority: 6 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: move cord drawing from pd to Tcl procs in pd-gui Initial Comment: This patch replaces the raw Tcl code in the 'pd' process' C code with two Tcl procs in pdtk_canvas: draw_signal_cord and draw_message_cord. This allows for customization of the cords from GUI plugins and Pd patches. This also is a step in the direction of making the 'pd' --> 'pd-gui' communications Pd messages rather than Tcl code. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2011-08-31 18:21 Message: Right-- when I said "drawing instructions" I really just meant where the line begins and ends. I can't see a case where this would be different between signal and control cords. Still, I wouldn't hard code values for the various options in those procs. Use variables. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-08-31 12:57 Message: (oops that was me not logged in) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-08-31 12:57 Message: You just answered your question :) The line width is one difference between signal and message cords. Another would be to have different colors, different line ending treatments, different patterns, etc. Some people might want to make Pd look like Max/MSP for example, and that has weird stripey cords. Another reason to have the signal/message conditional in C is speed. It'll execute much faster there. And really, I don't see the difference between adding a proc and adding another block in a if/then/else statement. Both are very straightforward and easy. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2011-08-31 01:59 Message: Oops, I guess "drawing instructions" is an ambiguous term. I just mean the coordinates: startx/y and endx/y. All the other options could be done with a conditional. BTW-- any reason you are hardcoding a width of "2" in that proc? Shouldn't it be something like -width $::signalcordwidth, with ::signalcordwidth being defined in pd-gui.tcl? (Could also use the options database but that's probably overkill.) ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2011-08-30 23:23 Message: I think you just need one proc with an arg corresponding to control/signal. All customization can be done elsewhere by referring to the tags. I can't think of any divergences between messagecord (controlcord?) and signalcord that would require different initial drawing instructions; all future features I can think of-- segmented cords or new cord selection/deletion/edition-- would be handled identically for both cases, no? If you disagree, could you give an example of a way in which a signalcord would ever require different drawing instructions than a controlwire? ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-08-30 12:36 Message: I think having separate procs/messages for each connection type makes it easier to customize. And its just as easy to add a proc for any new connection type as it is to add a block to a switch or something like that. Given that no new connection types have been added to Pd since its inception, I don't think its a high priority concern. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-30 03:09 Message: i haven't had a look yet, but wouldn't it be better to use a single tcl-proc "connect" (or "draw_cords") and specify the type of connection as an argument? this way it can be more easily expanded to other connection types. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3400300&group_…

1 0

[ pure-data-Patches-3400300 ] move cord drawing from pd to Tcl procs in pd-gui
by SourceForge.net 31 Aug '11

31 Aug '11

Patches item #3400300, was opened at 2011-08-29 15:08 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3400300&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: feature Status: Open Resolution: None Priority: 6 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: move cord drawing from pd to Tcl procs in pd-gui Initial Comment: This patch replaces the raw Tcl code in the 'pd' process' C code with two Tcl procs in pdtk_canvas: draw_signal_cord and draw_message_cord. This allows for customization of the cords from GUI plugins and Pd patches. This also is a step in the direction of making the 'pd' --> 'pd-gui' communications Pd messages rather than Tcl code. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-08-31 12:57 Message: (oops that was me not logged in) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-08-31 12:57 Message: You just answered your question :) The line width is one difference between signal and message cords. Another would be to have different colors, different line ending treatments, different patterns, etc. Some people might want to make Pd look like Max/MSP for example, and that has weird stripey cords. Another reason to have the signal/message conditional in C is speed. It'll execute much faster there. And really, I don't see the difference between adding a proc and adding another block in a if/then/else statement. Both are very straightforward and easy. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2011-08-31 01:59 Message: Oops, I guess "drawing instructions" is an ambiguous term. I just mean the coordinates: startx/y and endx/y. All the other options could be done with a conditional. BTW-- any reason you are hardcoding a width of "2" in that proc? Shouldn't it be something like -width $::signalcordwidth, with ::signalcordwidth being defined in pd-gui.tcl? (Could also use the options database but that's probably overkill.) ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2011-08-30 23:23 Message: I think you just need one proc with an arg corresponding to control/signal. All customization can be done elsewhere by referring to the tags. I can't think of any divergences between messagecord (controlcord?) and signalcord that would require different initial drawing instructions; all future features I can think of-- segmented cords or new cord selection/deletion/edition-- would be handled identically for both cases, no? If you disagree, could you give an example of a way in which a signalcord would ever require different drawing instructions than a controlwire? ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-08-30 12:36 Message: I think having separate procs/messages for each connection type makes it easier to customize. And its just as easy to add a proc for any new connection type as it is to add a block to a switch or something like that. Given that no new connection types have been added to Pd since its inception, I don't think its a high priority concern. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-30 03:09 Message: i haven't had a look yet, but wouldn't it be better to use a single tcl-proc "connect" (or "draw_cords") and specify the type of connection as an argument? this way it can be more easily expanded to other connection types. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3400300&group_…

1 0

[ pure-data-Patches-3400300 ] move cord drawing from pd to Tcl procs in pd-gui
by SourceForge.net 31 Aug '11

31 Aug '11

Patches item #3400300, was opened at 2011-08-29 19:08 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3400300&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: feature Status: Open Resolution: None Priority: 6 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: move cord drawing from pd to Tcl procs in pd-gui Initial Comment: This patch replaces the raw Tcl code in the 'pd' process' C code with two Tcl procs in pdtk_canvas: draw_signal_cord and draw_message_cord. This allows for customization of the cords from GUI plugins and Pd patches. This also is a step in the direction of making the 'pd' --> 'pd-gui' communications Pd messages rather than Tcl code. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-08-31 16:57 Message: You just answered your question :) The line width is one difference between signal and message cords. Another would be to have different colors, different line ending treatments, different patterns, etc. Some people might want to make Pd look like Max/MSP for example, and that has weird stripey cords. Another reason to have the signal/message conditional in C is speed. It'll execute much faster there. And really, I don't see the difference between adding a proc and adding another block in a if/then/else statement. Both are very straightforward and easy. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2011-08-31 05:59 Message: Oops, I guess "drawing instructions" is an ambiguous term. I just mean the coordinates: startx/y and endx/y. All the other options could be done with a conditional. BTW-- any reason you are hardcoding a width of "2" in that proc? Shouldn't it be something like -width $::signalcordwidth, with ::signalcordwidth being defined in pd-gui.tcl? (Could also use the options database but that's probably overkill.) ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2011-08-31 03:23 Message: I think you just need one proc with an arg corresponding to control/signal. All customization can be done elsewhere by referring to the tags. I can't think of any divergences between messagecord (controlcord?) and signalcord that would require different initial drawing instructions; all future features I can think of-- segmented cords or new cord selection/deletion/edition-- would be handled identically for both cases, no? If you disagree, could you give an example of a way in which a signalcord would ever require different drawing instructions than a controlwire? ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-08-30 16:36 Message: I think having separate procs/messages for each connection type makes it easier to customize. And its just as easy to add a proc for any new connection type as it is to add a block to a switch or something like that. Given that no new connection types have been added to Pd since its inception, I don't think its a high priority concern. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-30 07:09 Message: i haven't had a look yet, but wouldn't it be better to use a single tcl-proc "connect" (or "draw_cords") and specify the type of connection as an argument? this way it can be more easily expanded to other connection types. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3400300&group_…

1 0

Xcode 4: Debug pd-external
by Patrick Gampp 31 Aug '11

31 Aug '11

Hi, I tried to debug my puredata external with Xcode4. What I did so far is: 1) In the 'edit scheme'-menu, I added in the 'Executable'-list: Pd-extended.app. 2) Build configuration is Debug 3) Debugger is GDB. 4) I set some breakpoints in my source file. When I hit Run, pd starts and I open my patch, where the external is, which I want to debug. The patch runs, but Xcode does not stop at the given breakpoints. Do you know what I am doing wrong here? Thanks, Patrick

3 4

[ pure-data-Patches-3400300 ] move cord drawing from pd to Tcl procs in pd-gui
by SourceForge.net 31 Aug '11

31 Aug '11

Patches item #3400300, was opened at 2011-08-29 15:08 Message generated for change (Comment added) made by jancsika1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3400300&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: feature Status: Open Resolution: None Priority: 6 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: move cord drawing from pd to Tcl procs in pd-gui Initial Comment: This patch replaces the raw Tcl code in the 'pd' process' C code with two Tcl procs in pdtk_canvas: draw_signal_cord and draw_message_cord. This allows for customization of the cords from GUI plugins and Pd patches. This also is a step in the direction of making the 'pd' --> 'pd-gui' communications Pd messages rather than Tcl code. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2011-08-31 01:59 Message: Oops, I guess "drawing instructions" is an ambiguous term. I just mean the coordinates: startx/y and endx/y. All the other options could be done with a conditional. BTW-- any reason you are hardcoding a width of "2" in that proc? Shouldn't it be something like -width $::signalcordwidth, with ::signalcordwidth being defined in pd-gui.tcl? (Could also use the options database but that's probably overkill.) ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2011-08-30 23:23 Message: I think you just need one proc with an arg corresponding to control/signal. All customization can be done elsewhere by referring to the tags. I can't think of any divergences between messagecord (controlcord?) and signalcord that would require different initial drawing instructions; all future features I can think of-- segmented cords or new cord selection/deletion/edition-- would be handled identically for both cases, no? If you disagree, could you give an example of a way in which a signalcord would ever require different drawing instructions than a controlwire? ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-08-30 12:36 Message: I think having separate procs/messages for each connection type makes it easier to customize. And its just as easy to add a proc for any new connection type as it is to add a block to a switch or something like that. Given that no new connection types have been added to Pd since its inception, I don't think its a high priority concern. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-30 03:09 Message: i haven't had a look yet, but wouldn't it be better to use a single tcl-proc "connect" (or "draw_cords") and specify the type of connection as an argument? this way it can be more easily expanded to other connection types. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3400300&group_…

1 0

[ pure-data-Patches-3400300 ] move cord drawing from pd to Tcl procs in pd-gui
by SourceForge.net 31 Aug '11

31 Aug '11

1 0

[ pure-data-Patches-3400300 ] move cord drawing from pd to Tcl procs in pd-gui
by SourceForge.net 30 Aug '11

30 Aug '11

1 0

[ pure-data-Patches-3400300 ] move cord drawing from pd to Tcl procs in pd-gui
by SourceForge.net 30 Aug '11

30 Aug '11

Patches item #3400300, was opened at 2011-08-29 21:08 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3400300&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: feature Status: Open Resolution: None Priority: 6 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: move cord drawing from pd to Tcl procs in pd-gui Initial Comment: This patch replaces the raw Tcl code in the 'pd' process' C code with two Tcl procs in pdtk_canvas: draw_signal_cord and draw_message_cord. This allows for customization of the cords from GUI plugins and Pd patches. This also is a step in the direction of making the 'pd' --> 'pd-gui' communications Pd messages rather than Tcl code. ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-30 09:09 Message: i haven't had a look yet, but wouldn't it be better to use a single tcl-proc "connect" (or "draw_cords") and specify the type of connection as an argument? this way it can be more easily expanded to other connection types. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3400300&group_…

1 0

[ pure-data-Patches-3400300 ] move cord drawing from pd to Tcl procs in pd-gui
by SourceForge.net 29 Aug '11

29 Aug '11

Patches item #3400300, was opened at 2011-08-29 15:08 Message generated for change (Tracker Item Submitted) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3400300&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: feature Status: Open Resolution: None Priority: 6 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: move cord drawing from pd to Tcl procs in pd-gui Initial Comment: This patch replaces the raw Tcl code in the 'pd' process' C code with two Tcl procs in pdtk_canvas: draw_signal_cord and draw_message_cord. This allows for customization of the cords from GUI plugins and Pd patches. This also is a step in the direction of making the 'pd' --> 'pd-gui' communications Pd messages rather than Tcl code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3400300&group_…

1 0

iemlib help patch revisions
by Jonathan Wilkes 29 Aug '11

29 Aug '11

Hi, I have revised the iemlib help patches to include the [pd META] subpatch. Who do I give them to to commit? Or do I just do it myself? Same question for all the other iemlibs. Thanks, Jonathan

3 4

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 August 2011