Pd-dev April 2010

pd-dev@lists.iem.at

9 participants
129 discussions

[ pure-data-Bugs-2989552 ] type-punned pointers break strict aliasing rules
by SourceForge.net 19 Apr '10

19 Apr '10

Bugs item #2989552, was opened at 2010-04-19 20:01 Message generated for change (Tracker Item Submitted) made by claudiusmaximus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2989552&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-devel Group: v0.43 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ClaudiusMaximus (claudiusmaximus) Assigned to: Nobody/Anonymous (nobody) Summary: type-punned pointers break strict aliasing rules Initial Comment: the current development version of Pd (well, assuming the gui-rewrite 0.43 branch is it) stiill suffers from a lot type-punned pointers that break strict aliasing rules (and would better be replaced by unions). See here for some rationale http://lists.puredata.info/pipermail/pd-dev/2007-10/009677.html Some command line hackery to print out some stats: ----8<---- claude@zebimus:~/code/pure-data_branches_pd-gui-rewrite_0-43$ make CFLAGS="-fstrict-aliasing -Wall" 2>&1 | grep warning.*strict | sort | sed "s|: warning.*||" | uniq | sed "s|:| |" | sort -V | ( oldsrc="none" ; while read src lineno ; do if [ $src = $oldsrc ] ; then echo $lineno ; else echo $src $lineno ; fi ; oldsrc=$src ; done ) | sed "s|$._.*$|;\1|" | tr "\n;" " \n" | tail -n+2 && echo d_array.c 61 727 d_ctl.c 110 145 327 d_delay.c 88 d_filter.c 72 174 305 307 390 577 810 812 d_math.c 87 101 109 d_osc.c 437 439 d_soundfile.c 252 253 254 285 287 290 298 299 321 337 339 346 355 356 371 987 998 1095 1106 ----8<---- (That's a table of files with line numbers that exhibit the problem) While replacing (*(inttype *)&floatvalue) with a (union {inttype i; floattype f; } u;) is almost trivial, it's slightly less trivial to do it the right way. The right way involves taking into account that Pd can be now be compiled to use double instead of float, so you need a different sized inttype for each case The later 32bit bit-twiddling will probably break in that case anyway, so maybe better to have a compile-time check if it will work, and if not then do it the naive way...). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2989552&group_…

1 0

[ pure-data-Bugs-2989541 ] iem_matrix
by SourceForge.net 19 Apr '10

19 Apr '10

Bugs item #2989541, was opened at 2010-04-19 19:30 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2989541&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: iem_matrix Initial Comment: objects like mtx_.^, mtx./ do not load automatically, even after adding the path to startup ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2989541&group_…

1 0

[ pure-data-Bugs-2989444 ] bang to [ascseq] causes crash
by SourceForge.net 19 Apr '10

19 Apr '10

Bugs item #2989444, was opened at 2010-04-19 12:08 Message generated for change (Tracker Item Submitted) made by jancsika1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2989444&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: Jonathan Wilkes (jancsika1) Assigned to: Nobody/Anonymous (nobody) Summary: bang to [ascseq] causes crash Initial Comment: Pd version 0.42.5-extended-20100415, winxp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2989444&group_…

1 0

[ pure-data-Bugs-2621932 ] gop multiplicity
by SourceForge.net 17 Apr '10

17 Apr '10

Bugs item #2621932, was opened at 2009-02-21 01:44 Message generated for change (Comment added) made by sistisette 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: Matteo Sisti Sette (sistisette) Date: 2010-04-17 20:45 Message: It has just happened to me while using Pd with NO GOP at all. I was editing some very minimal patch, including some help-patch. I did however use (and open/close/copy/paste) subpatches and had at least a toggle in the patch I was using; i think that only single toggle was the only gui object at all, in any case I can assure there was no GOP involved ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2010-03-18 23:52 Message: Do i understand correctly: the last comment mean that the fix was not a fix? Would you agree on raising the priority of this bug? This is a crasher, and even before the crash it renders Pd unusable _very_ soon when editing gop patches.... ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-01-18 07:07 Message: I removed commit r12831, canvas_destory_editor() is already being called in the canvas_free() process within canvas_vis(x, 0). I don't know the source of this bug tho, I'll look into it more. ---------------------------------------------------------------------- Comment By: Mathieu Bouchard (matju) Date: 2009-12-13 04:45 Message: i just fixed it in revision 12831, pd-extended/0.42 ---------------------------------------------------------------------- Comment By: Mathieu Bouchard (matju) Date: 2009-12-13 04:29 Message: editor_new gets called for a gop, but editor_free does not. ---------------------------------------------------------------------- Comment By: Mathieu Bouchard (matju) Date: 2009-12-13 04:24 Message: t_guiconnect registers a receive-symbol for any canvas but deleting a gop does not unregister the receive-symbol. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2009-12-11 15:21 Message: Oh shit, it only disappears with the reporter's test patch, but I have experimented the bug also with -noautopatch ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2009-12-11 15:19 Message: I have tested with -noautopatch, which disables the belowmentioned feature, and the bug disappears. So it is definitely related to that feature, dunnow how. Hope this helps m. P.S. can anybody confirm? ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2009-12-11 13:26 Message: Hi, This bug seem to have APPEARED ON VERSION 0.42.0 At least, I tested it with the reporter's patch on 0.41.4 and it works fine, while on 0.42.0 the bug shows up 100% of the time. That is the same version in which the (very annoying) feature was introduced that when you create a new object and another one is selected, a connection is automatically created. May the bug be related to the introduction of that feature? ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2009-12-11 12:48 Message: I confirm I can 100% reproduce it on Windows Vista with 0.42-4. Unfortunately I am only a user so I cannot help. I have also encountered the same problem; my patch is too big and complex to attach it, but in my case I can reproduce the problem by just: A - loading the main patch B - closing it C - loading it again And I get the "mulyiplicity" in the main patch, not any subpatch. But not with your patch. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2009-11-27 01: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 11: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 16: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

[ pure-data-Bugs-2957058 ] a pointer to [route] crashes; [route] lacks a 'pointer' type
by SourceForge.net 17 Apr '10

17 Apr '10

Bugs item #2957058, was opened at 2010-02-23 06:11 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&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.43 Status: Open Resolution: None Priority: 7 Private: No Submitted By: Jonathan Wilkes (jancsika1) Assigned to: Miller Puckette (millerpuckette) Summary: a pointer to [route] crashes; [route] lacks a 'pointer' type Initial Comment: [namecanvas foo] [traverse foo, bang( | [pointer] | [route symbol] | [print] 1) a pointer message is erroneously routed as a symbol 2) this crashes Pd 3) [route pointer] doesn't route a pointer ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-04-17 17:56 Message: a message from matju to the other anonymous person who wrote on march 1st : GridFlow's [print] started stripping leading "float" and "list" at one point in the last few months... and a A_POINTER can't possibly be a selector EVER. therefore, the only other possibility, is that [route] is outputting things with the "list" selector instead of "pointer", which is already what it does with "float" messages. I don't know what happens after that, with the crashes and stuff. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2010-04-13 06:01 Message: Hans, The crash is caused by any object which attempts to display the output: the<crtl-4> symbol box, [set $1( -- [ ( both cause the crash as well. The [route] object is outputting a symbol message with some mutant value (I assume the selector is 'symbol' because if you hook [route] to a [vsl], for example, you get "no method for 'symbol'" ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-04-13 03:31 Message: There are a number of "types" in pd: [symbol] [float] [list] [bang] [pointer] [trigger symbol float list bang pointer] [route] does [route symbol float list bang] so it is inconsistent that [route pointer] would not route the "pointer" atom type, and instead route based on the "pointer" as a symbolic selector. That right there is a bug IMHO. As for the crash, I could also reproduce it using Pd version 0.42.5-extended-20100410 or pd-gui-rewrite 0.43 on Mac OS X 10.5.8/Intel. The crash is actually in the [print], not the [route]. When I remove the [print], it doesn't crash. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2010-03-01 21:58 Message: Oops, I didn't realize that when lists get distributed the atoms are interpreted, just like the [list] object classes. E.g., I though the following would output an error but it works fine: [list one two( | [select symbol] You know, since [route list] has different behaviors depending on whether the first element is a float or symbol, the same could be done for [route pointer]-- strip the selector off of anythings, pass gpointer messages through unchanged. That way there is at least some consistency, in the sense that the selector is always being matched. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-03-01 18:41 Message: Hi Jonathan, that's not really what I meant. You can use pointers in a list-message of course ("list <pt1> <pt2> <pt3>") or [pack/unpack] many of them and so on. Even [pipe] works with pointers and lists of pointers now. But when you strip a lone pointer from it's selector then the pointer itself could become the selector like: "list set 2"->[route list] becomes "set 2" and this will call the "set"-method of the next object. If this is a message box it will be set to "2". But with a pointer you'd get "pointer <pt>" -> [route pointer] -> "<pt>", so now it would try to use some "<pt>" method, which is probably undefined. BTW: I guess that's what leads to the crash here. I think selectors must be symbols. So to make use of the pointless pointer (pun intended :) one probably has to attach a selector again with [list] or [pointer] or something. Anyway I guess we're now talking about the usefulness of route's implementation, which is debatable and led to the development of several nicer variants in GridFlow. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2010-03-01 17:48 Message: Hi Frank, Is it really useless? If you send a gpointer through the following, it works: [rewind $1( | [pointer] That's a meta message consisting of a symbol-atom and a pointer-atom. And the pointer atom gets sent successfully to the right inlet. However, I can't currently find a way to test sending a single pointer-atom to the left inlet. (If you try to strip it with list trim you always end up with the "list" selector.) ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2010-03-01 12:16 Message: I meant to write: useless just like a "gem_state" stripped of its *selector*. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2010-03-01 12:15 Message: First I have to correct myself: The selector of a pointer-message is indeed "pointer", as can be seen with zexy's new rawprint object or by exploiting the error message of an object like [select] when sent a pointer which is "no method for 'pointer'". So "route pointer" could or maybe should indeed route a "pointer" meta-message just like it can route a "gem_state" message However as [route] also strips off the selector you would be left with just the pointer that is more or less useless just like a "gem_state" stripped of its pointer cannot be used in the gem chain anymore. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2010-03-01 03:11 Message: (pointer) with the g missing is what is specified in m_atom.c for displaying a pointer atom. So I assume there's a difference between a pointer message and a pointer atom. There are two reasons to [route] pointer messages. 1) Didactic-- [route] is a common object people use to learn about the behavior of messages in Pd. It would be nice to show all the predefined message types going to different outlets, which can't currently happen because [route] doesn't differentiate between pointers and anythings. 2) Because anythings and pointers aren't differentiated, this diminishes the flexibility of an abstraction inlet. So a data-structure related abstraction that wants to take "set," "flush", "clear", and pointer messages to the left inlet and do something else with the right inlet has to add an additional inlet. The [pointer] object can differentiate between a pointer and "rewind," for example. An abstraction should be able to have the same flexibility. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2010-02-25 16:37 Message: Yep, a gpointer is not simply a message composed of "pointer" and some actual pointer blob. I don't know the exact details myself and don't really understand the source code, but they seem to be something very "special" just like signals are. As you know, [print] shows them as a not very helpful "(gpointer)", but if you pass a pointer to [list prepend set]-[list trim] and into a message box: There pointers show up as "(pointer)" with the "g" missing. Anyway don't bother trying [route (pointer)], it doesn't work either. :) In the end we probably have to accept that gpointers don't have a "printable" selector, just like audio signals don't have one. Introducing a print- and routable selector as "pointer" may be useful, or maybe it's not, as some people may already use "pointer" as a meta-message in their patches, for example to handle mouse-"pointer" events or so. ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2010-02-25 05:54 Message: Hm, I'm just not understanding something about gpointers-- I'd just assumed when you send a pointer message it consists of the selector "pointer" followed by the gpointer itself (gridflow's [display] seems to confirm this). But clearly something else is going on because [route pointer] doesn't currently work for gpointers, nor will [pointer] accept a gpointer that has passed through [pointer $1( (though [route] will, without crashing, and output a usable gpointer that has the selector "list"). It also seems like "pointer 1 2 3" is an unchecked case of "bad arguments to message 'pointer'". So I guess I'm saying I agree that [route pointer] should route according to the selector "pointer", I just don't understand why a gpointer wouldn't match under those conditions. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2010-02-23 08:40 Message: Hi Jonathan, I raised the priority as crashes are really serious. I disagree with your item 3), though. [route pointer] should not route GPointers, but meta-messages starting with the symbol "pointer" e.g. [pointer 1 2 3( | [route pointer] | It does that just fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&group_…

1 0

[ pure-data-Bugs-2957057 ] pddplink and pddp/dsp don't play well together
by SourceForge.net 15 Apr '10

15 Apr '10

Bugs item #2957057, was opened at 2010-02-23 01:06 Message generated for change (Settings changed) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957057&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.42 >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Jonathan Wilkes (jancsika1) Assigned to: Hans-Christoph Steiner (eighthave) Summary: pddplink and pddp/dsp don't play well together Initial Comment: If you use pddplink and pddp/dsp in the same patch, pddplink gives the following error: pddplink: internal error (open [path to the file shown in the link] ) This is caused by [r pd] in pddp/dsp. (Matju wrote something on the list about why this happens, but I can't seem to find it at the moment) ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-04-15 01:09 Message: woops, forgot to include the pddplink.tcl file in the install, should be fixed in tomorrow's build ---------------------------------------------------------------------- Comment By: Jonathan Wilkes (jancsika1) Date: 2010-04-14 18:53 Message: As of Pd version 0.42.5-extended-20100414, [pddplink] doesn't do anything at all when clicked in winxp. On Hardy, if you start it from a terminal, the following message is sent to the terminal when you click the link: invalid command name "pddplink_open" ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-04-12 23:21 Message: I couldn't reproduce this with Pd version 0.42.5-extended-20100405 on Mac OS X 10.5.8/Intel but I suspect it was also fixed by recent pddplink changes for bugs 2960967 and 2959373 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957057&group_…

1 0

can't load gemlib
by Lee Azzarello 15 Apr '10

15 Apr '10

Debian testing 32 bit Linux musicmachine 2.6.32-trunk-686-bigmem #1 SMP Sun Jan 10 07:12:17 UTC 2010 i686 GNU/Linux pd-extended version 0.41.4-1 Debian package from http://apt.puredata.info squeeze libdir loader $Revision: 1.8 $ compiled on Jun 4 2009 at 07:17:39 compiled against Pd version 0.41.4.extended /usr/lib/pd/extra/Gem/Gem.pd_linux: /usr/lib/pd/extra/Gem/Gem.pd_linux: undefined symbol: _ZN3avm14CreateReadFileEPKcj Gem: can't load library wha happen? OpenGL library or sumn? ldd /usr/lib/pd/extra/Gem/Gem.pd_linux reports 74 libraries linked against that single external, so I'm gonna need some help narrowing this down. -lee

3 3

[ pure-data-Bugs-2957057 ] pddplink and pddp/dsp don't play well together
by SourceForge.net 15 Apr '10

15 Apr '10

Bugs item #2957057, was opened at 2010-02-23 01:06 Message generated for change (Comment added) made by jancsika1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957057&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.42 >Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan Wilkes (jancsika1) Assigned to: Hans-Christoph Steiner (eighthave) Summary: pddplink and pddp/dsp don't play well together Initial Comment: If you use pddplink and pddp/dsp in the same patch, pddplink gives the following error: pddplink: internal error (open [path to the file shown in the link] ) This is caused by [r pd] in pddp/dsp. (Matju wrote something on the list about why this happens, but I can't seem to find it at the moment) ---------------------------------------------------------------------- >Comment By: Jonathan Wilkes (jancsika1) Date: 2010-04-14 18:53 Message: As of Pd version 0.42.5-extended-20100414, [pddplink] doesn't do anything at all when clicked in winxp. On Hardy, if you start it from a terminal, the following message is sent to the terminal when you click the link: invalid command name "pddplink_open" ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-04-12 23:21 Message: I couldn't reproduce this with Pd version 0.42.5-extended-20100405 on Mac OS X 10.5.8/Intel but I suspect it was also fixed by recent pddplink changes for bugs 2960967 and 2959373 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957057&group_…

1 0

[ pure-data-Bugs-2987237 ] patches with two windows don't close properly
by SourceForge.net 14 Apr '10

14 Apr '10

Bugs item #2987237, was opened at 2010-04-14 13:31 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2987237&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.42 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) >Assigned to: Hans-Christoph Steiner (eighthave) Summary: patches with two windows don't close properly Initial Comment: If you open 4.data.structures/08.selection.pd then hit the Cmd-W key to close the window, it closes the window behind, and then you can't close the front window with the key command. Pd version 0.42.5-extended-20100414 Mac OS X 10.5.8 ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-04-14 15:32 Message: fixed in 0.43 pd-gui-rewrite ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2987237&group_…

1 0

[ pure-data-Bugs-2987237 ] patches with two windows don't close properly
by SourceForge.net 14 Apr '10

14 Apr '10

Bugs item #2987237, was opened at 2010-04-14 13:31 Message generated for change (Tracker Item Submitted) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2987237&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: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody) Summary: patches with two windows don't close properly Initial Comment: If you open 4.data.structures/08.selection.pd then hit the Cmd-W key to close the window, it closes the window behind, and then you can't close the front window with the key command. Pd version 0.42.5-extended-20100414 Mac OS X 10.5.8 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2987237&group_…

1 0

← Newer
1
2
3
4
5
6
7
8
...
13
Older →

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 2010