Pd-dev November 2009

pd-dev@lists.iem.at

19 participants
65 discussions

[ pure-data-Bugs-2905413 ] mrpeach/tcpserver: messages to clients are doubled
by SourceForge.net 28 Nov '09

28 Nov '09

Bugs item #2905413, was opened at 2009-11-28 18:15 Message generated for change (Settings changed) made by reduzent You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905413&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roman Haefeli (reduzent) >Assigned to: Martin Peach (mrpeach) Summary: mrpeach/tcpserver: messages to clients are doubled Initial Comment: hello martin I was told, that [tcpserver] was updated to use threading now. so i wanted to test the new version. on my machine, it is not working correctly yet. messages sent from [tcpserver] are doubled for some reason. when sending this message with [tcpserver] (it doesn't matter, whether i use the 'send <socketnumber>' or the 'broadcast' method): 97 98 99 100 101 102 103 104 105 i get this on the client side: 97 98 99 100 101 102 103 104 105 97 98 99 100 101 102 103 104 105 sometimes even this: 97 97 98 99 100 101 102 103 104 105 98 99 100 101 102 103 104 105 this is with [tcpserver] compiled from svn checkout from today on pd-0.42.5 on ubuntu 9.10. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905413&group_…

1 0

[ pure-data-Bugs-2905413 ] mrpeach/tcpserver: messages to clients are doubled
by SourceForge.net 28 Nov '09

28 Nov '09

Bugs item #2905413, was opened at 2009-11-28 18:15 Message generated for change (Tracker Item Submitted) made by reduzent You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905413&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roman Haefeli (reduzent) Assigned to: Nobody/Anonymous (nobody) Summary: mrpeach/tcpserver: messages to clients are doubled Initial Comment: hello martin I was told, that [tcpserver] was updated to use threading now. so i wanted to test the new version. on my machine, it is not working correctly yet. messages sent from [tcpserver] are doubled for some reason. when sending this message with [tcpserver] (it doesn't matter, whether i use the 'send <socketnumber>' or the 'broadcast' method): 97 98 99 100 101 102 103 104 105 i get this on the client side: 97 98 99 100 101 102 103 104 105 97 98 99 100 101 102 103 104 105 sometimes even this: 97 97 98 99 100 101 102 103 104 105 98 99 100 101 102 103 104 105 this is with [tcpserver] compiled from svn checkout from today on pd-0.42.5 on ubuntu 9.10. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905413&group_…

1 0

Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
by Hans-Christoph Steiner 28 Nov '09

28 Nov '09

Could you post the full pd.tk and the version of Pd its it supposed to work with? Also: - I attached a quick stab at turning your scrollbar logic into a 0.43 GUI plugin. It doesn't work because your code relies on Pd-extended 0.42 things, but if you make your algorithm into a plugin using this framework, then people can just drop the file into the pd/startup folder to use your algorithm. - I created a wiki page to document this whole process, please add any tests that you can think of here: http://puredata.info/dev/ScrollBarLogic .hc On Nov 18, 2009, at 10:37 AM, Ivica Ico Bukvic wrote: > OK, try the one below instead (with ::scroll call removed). Also, > plase > don't forget to do the followign test with large graphics objects and > test scrollbar behavior: > > 1) create iemlib's number2 > 2) adjust its height to 60 and its font size to 50 > 3) drag it as far to the top as possible and what you will likely > discover is that it fails to reach the top corner *or* creates > scrollbars even though the object fits comfortably within the window. > This is not the case AFAIK with the version below. > > Ico > > > proc pdtk_canvas_getscroll {name} { > global pdtk_canvas_mouseup_name > global pdtk_canvas_mouseup_xminval > global pdtk_canvas_mouseup_xmaxval > global pdtk_canvas_mouseup_yminval > global pdtk_canvas_mouseup_ymaxval > > #bbox all is not accurate enough > #particularly when using large iemlib objects > #so we calculate canvas size manually > #set size [$name bbox all] > > #borrowed from http://wiki.tcl.tk/4844 > set x1 1.0e30; set x2 -1.0e30 ; > set y1 1.0e30; set y2 -1.0e30 ; > foreach item [$name find all] { > switch -exact [$name type $item] { > "arc" - > "line" - > "oval" - > "polygon" - > "rectangle" { > set coords [$name coords $item] > foreach {x y} $coords { > if { $x < $x1 } {set x1 $x} > if { $x > $x2 } {set x2 $x} > if { $y < $y1 } {set y1 $y} > if { $y > $y2 } {set y2 $y} > } > } > } > } > > if {$x1 != 1.0e30} { > > set xminval 0 > set yminval 0 > set xmaxval 100 > set ymaxval 20 > #set x1 [lindex $size 0] > #set x2 [lindex $size 2] > #set y1 [lindex $size 1] > #set y2 [lindex $size 3] > > #pdtk_post "bbox all: $x1 $x2 $y1 $y2\n" > #pdtk_post "new bbox all: $xbox1 $xbox2 $ybox1 $ybox2\n" > > #these work much better than the ones below > #they allow for intelligent translation of the canvas > #rather than introducing redundant scrollbars > set xminval $x1 > set yminval $y1 > > set xmaxval [expr $x1+($x2-$x1)] > set ymaxval [expr $y1+($y2-$y1)] > > #if {$x1 < $xminval} {set xminval $x1} > #if {$y1 < $yminval} {set yminval $y1} > > #if {$x2 > $xmaxval} {set xmaxval $x2} > #if {$y2 > $ymaxval} {set ymaxval $y2} > > #pdtk_post "$xminval $xmaxval $yminval $ymaxval\n" > > set parentname [winfo parent $name] > set winwidth [winfo width $parentname] > set winheight [winfo height $parentname] > > set canvaswidth [ expr {abs($xmaxval-$xminval)} ] > set canvasheight [ expr {abs($ymaxval-$yminval)} ] > #set canvaswidth [ expr {abs($xminval)+$xmaxval} ] > #set canvasheight [ expr {abs($yminval)+$ymaxval} ] > > #pdtk_post "$canvaswidth $canvasheight\n" > > #pdtk_post "$parentname [$parentname.scroll cget -state]\n" > > #pdtk_post "scroll=yes $winwidth $canvaswidth\n" > if {$winwidth > $canvaswidth} {pack forget $parentname.scrollhort} > if {$winheight > $canvasheight} {pack forget > $parentname.scrollvert} > if {$winwidth < $canvaswidth} {pack $parentname.scrollhort -fill > x \ > -side bottom -before $parentname.c} > if {$winheight < $canvasheight} {pack $parentname.scrollvert - > fill y > \ > -side right -before $parentname.c} > > > if {$pdtk_canvas_mouseup_name != $name || \ > $pdtk_canvas_mouseup_xminval != $xminval || \ > $pdtk_canvas_mouseup_xmaxval != $xmaxval || \ > $pdtk_canvas_mouseup_yminval != $yminval || \ > $pdtk_canvas_mouseup_ymaxval != $ymaxval } { > > set newsize "$xminval $yminval $xmaxval $ymaxval" > $name configure -scrollregion $newsize > set pdtk_canvas_mouseup_name $name > set pdtk_canvas_mouseup_xminval $xminval > set pdtk_canvas_mouseup_xmaxval $xmaxval > set pdtk_canvas_mouseup_yminval $yminval > set pdtk_canvas_mouseup_ymaxval $ymaxval > } > } > pdtk_canvas_checkgeometry [canvastosym $name] > } > > ---------------------------------------------------------------------------- "Making boring techno music is really easy with modern tools," he says, "but with live coding, boring techno is much harder." - Chris McCormick

3 4

Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
by Ivica Ico Bukvic 28 Nov '09

28 Nov '09

I think we are confusing two things here, the whole pd.tk which does offer Hans-Christoph Steiner <hans(a)at.or.at> wrote: > >On Nov 18, 2009, at 10:47 AM, Ivica Ico Bukvic wrote: > >> Please see attached. This one should work seamlessly on pd-extended >> 0.42.5 with Linux (it has *not* been tested with other platforms even >> though the basic premise of the redesign is that it should). >> >> Ico >> <pdtk.tar.gz> > >FYI, it doesn't work on Mac OS X because it requires 8.5 and ttk, so >this couldn't be included in vanilla since Miller wants to continue to >support 8.3, and it couldn't be included in Pd-extended until 0.43 >since 0.42 doesn't work on Mac OS X with 8.5 > >Error in startup script: invalid command name "ttk::style" > while executing >"ttk::style configure IOErrorOn.TButton -background "#dd2222"" > (file "/Applications/Pd-0.42.5-extended-20091112.app/Contents/ >Resources/Scripts/AppMain.tcl" line 416) > >.hc > > >---------------------------------------------------------------------------- > >I hate it when they say, "He gave his life for his country." Nobody >gives their life for anything. We steal the lives of these kids. - >Admiral Gene LeRocque >

1 0

[ pure-data-Feature Requests-2904773 ] print subpatch/abstraction name in GOP bounding box
by SourceForge.net 27 Nov '09

27 Nov '09

Feature Requests item #2904773, was opened at 2009-11-26 20:06 Message generated for change (Tracker Item Submitted) made by jancsika1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=2904773&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 Priority: 5 Private: No Submitted By: Jonathan Wilkes (jancsika1) Assigned to: Nobody/Anonymous (nobody) Summary: print subpatch/abstraction name in GOP bounding box Initial Comment: When using GOP with "hide object name and arguments" unchecked, it would be handy to print the name of the subpatch/abstraction within the red bounding box in the subpatch/abstraction itself. This would provide a point of reference that would help avoid collisions between GOP objects and the name of the subpatch/abstraction. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=2904773&group_…

1 0

[ pure-data-Bugs-2621932 ] gop multiplicity
by SourceForge.net 27 Nov '09

27 Nov '09

Bugs item #2621932, was opened at 2009-02-20 19:44 Message generated for change (Comment added) made by jancsika1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2621932&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: gop multiplicity Initial Comment: 1. Open patch.pd 2. Delete the subpatch. 3. Either a) create a new my_abs object or b) undo the previous delete 4. Repeat steps 2-3 n times. Now when you open the subpatch, all actions occur n+1 times, e.g.: * creating a new object box makes a chain of n+1 object boxes * patch is saved n+1 times * paste creates n+1 new copies If you don't save and try to close patch.pd, it repeats the message "discard changes to patch.pd" and sometimes crashes after two or three times. The behavior persists until closing pd completely. So if you go through the steps above 3 times, close the patch, and reopen it and go through them 3 more times, you'll get 7 extra objects every time you create something from the "put" menu. I only get this behavior when using gop, and with an object visible in the gop window. Same for abstractions. For each extra object created in the subpatch, I get a "consistency check failed: canvas_vis" error to the console. Using pd-0.42-4 on windows xp sp3 -Jonathan jancsika(a)yahoo.com ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2009-11-26 19:44 Message: I forgot to say I'm using winxp sp3 with pd vanille 0.42-5 to produce the behavior in the attached patch ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-04-03 05:07 Message: In step #3 above, please ignore "a) create a new my_abs object" and simply undo the previous deletion of the subpatch. Also, the multiplicity bug happens only within the subpatch window. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-04-02 10:26 Message: could not reproduce with 0.42-4 on linux ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2621932&group_…

1 0

Re: [PD-dev] puredata.info timing out.
by matju＠artengine.ca 25 Nov '09

25 Nov '09

On Mon, 23 Nov 2009, Forwind info wrote: > Has anyone else noticed that puredata.info is timing out. This has been > happening to me from London for the past 2 days ? As far as I am aware this > is all hosted at IEM, IOhannes (presuming you are still at iem) ? It was down for everybody. The puredata.info machine froze for the second or third time or more. The hardware (or any part thereof) will be changed eventually. Johannes can tell you more about this. _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801

2 1

ATTENTION to all pd-list and pd-dev users!
by Mathieu Bouchard 24 Nov '09

24 Nov '09

If you have any mails that timed out after 1 or 2 days, you should re-send them, and now is the time! Note that it says "Permanent failure" in that case, and not "Temporary failure" (The latter of which means: it's still on auto-retry) Some mail servers auto-retry for only 1 day, some others auto-retry for 4 days. (I have no idea how many are one way or the other but I've seen both). When a mail is on auto-retry, it may take a few hours until the next retry. Some threads may be received in the wrong order, but fortunately, the "Date:" field still works, etc. _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801

2 1

Re: [PD-dev] bug when redrawing gop within gop inside a closed sub-patch
by Mathieu Bouchard 24 Nov '09

24 Nov '09

On Mon, 23 Nov 2009, Ivica Ico Bukvic wrote: > You need to cycle through cords of a visible canvas b/c even though a > canvas is open they may not be placed in a visible part of that canvas. The bug is happening because a given pd canvas doesn't have a corresponding tk canvas. This happens when the canvas is said to be «closed». When a window is minimised, it's just useless to send the «raise» command, but it doesn't cause an error message. In the case of GOP, the canvas' contents is visible, but the associated tk canvas does not an id matching the pointer of the pd canvas. > Of course lingering question is what is in the end faster in tcl/tk > land: cycling through objects and refreshing them (which would be the > cleaner thing to do) Why would it be the cleaner thing to do? It's not like simpler, smaller commands are full of doorknob viruses. Tk has the commands on groups of items so that it acts on groups of items, I don't know why we're supposed to avoid that feature and call it cleaner. > or simply refreshing entire canvas and trusting that tcl/tk is > implemented so efficiently that its execution offsets time required for > redundant redraws. What about trusting that tcl/tk is implemented so efficiently that when you are picking each element in the manner that they are sorted already, and raising each of them separately to the top (thus changing the order of N cords N times in a row), tcl/tk would figure out that it has nothing to redraw?... I wouldn't even be sure that *any* toolkit would figure out that situation. Whereas for raise all_cords, tcl/tk guarantees it preserves the relative order of members of all_cords, so it is possible and likely that it will figure out that nothing has changed (but not certain). tcl/tk is notoriously inefficient but it's also very easy to make wrong guesses as to what will be done redundantly and what won't. If you are interested in accelerating your code Tk-wise, I could show you what I found about Tk's redrawing when I tried to modify tk/generic/tkCanvas.c. _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801

2 4

bug when redrawing gop within gop inside a closed sub-patch
by Ivica Ico Bukvic 24 Nov '09

24 Nov '09

Please see attached patch. it appears whenever there is change in the gui of a closed sub-patch that has GOP sub-patch showing another GOP-ed subpatch (try reading that aloud) the redraw is attempted resulting in an error in a console. Probably the best thing is to test the attached patch. The good news--this is a non-lethal bug. Basically run pd from terminal, open the patch and try changing the symbol value. You will likely get an error on the shell (not Pd console) stating: invalid command name ".x89d1d08.c" (or whatever the name is of the sub-patch) Now if you open the sub-patch [pd tester] that has a subpatch with GOP and another one below it in a GOP (visible through parent GOP), everything is fine. #N canvas 258 155 296 207 10; #X symbolatom 115 54 10 0 0 0 - - -; #X obj 115 76 s test; #N canvas 538 176 297 192 tester 0; #N canvas 7 175 450 300 asdasdasda 0; #N canvas 2 50 450 300 blah 0; #X symbolatom 110 120 10 0 0 0 - - -; #X obj 113 29 r test; #X obj 98 61 prepend set; #X connect 1 0 2 0; #X connect 2 0 0 0; #X coords 0 -1 1 1 85 60 1 100 100; #X restore 127 119 pd blah; #X coords 0 -1 1 1 150 90 1 100 100; #X restore 66 44 pd asdasdasda; #X coords 0 0 1 1 300 80 0; #X restore 108 112 pd tester; #X connect 0 0 1 0; Ico

3 21

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 November 2009