Pd-dev July 2008

pd-dev@lists.iem.at

25 participants
100 discussions

[ pure-data-Bugs-2007191 ] [sssad] does not create on pd-extended
by SourceForge.net 21 Jul '08

21 Jul '08

Bugs item #2007191, was opened at 2008-06-30 22:44 Message generated for change (Comment added) made by boonier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2007191&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: hardoff (hardoff) Assigned to: Hans-Christoph Steiner (eighthave) Summary: [sssad] does not create on pd-extended Initial Comment: there is a similar bug report below, but here are further details: creating a [sssad] object in pd-extended causes the following error in the console: libdir_loader: added 'sssad' to the canvas-local objectclass path libdir_loader: added 'sssad' to the canvas-local objectclass path libdir_loader: added 'sssad' to the canvas-local objectclass path ...about 1000 times, and then finally says: error: maximum object loading depth 1000 reached sssad ... couldn't create several people have suggested that there is a glitch in the libdir loader that won't allow for an abstraction to have the same name as its enclosing folder. ---------------------------------------------------------------------- Comment By: boonier (boonier) Date: 2008-07-21 21:21 Message: Logged In: YES user_id=1915214 Originator: NO my apologies - i wasnt logged in... smills[at]rootsix.net ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2007191&group_…

1 0

[ pure-data-Bugs-2004979 ] hid defaults to debugging (flood of "hid_get_events")
by SourceForge.net 21 Jul '08

21 Jul '08

Bugs item #2004979, was opened at 2008-06-28 06:28 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2004979&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: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Frank Barknecht (fbar) Assigned to: Hans-Christoph Steiner (eighthave) Summary: hid defaults to debugging (flood of "hid_get_events") Initial Comment: It seems, [hid] still defaults to have debugging on which results in a flood of "hid_get_events" messages to the console, when polling is on, unless one sends [debug 0( to [hid] Also see http://lists.puredata.info/pipermail/pd-list/2007-01/046275.html ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-06-28 13:14 Message: Logged In: YES user_id=27104 Originator: NO One Pd-extended 0.40.3 is released, I'll merge all of the changes into trunk (this is a fairly standard way to deal with release branches). In the meantime, I recommend you use the release version. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-06-28 08:05 Message: Logged In: YES user_id=569446 Originator: YES I'm using the "trunk", not a branch. I did a "cd trunk/externals; make hid" as told in hid's README. It still starts with debugging then. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-06-28 06:58 Message: Logged In: YES user_id=27104 Originator: NO I just fixed this and some other bugs and annoyances with [hid]. This should be fixed by this commit, let me know if it is not: http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-extended/… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2004979&group_…

4 12

[ pure-data-Bugs-2023949 ] Add Path dialog won't accept/save new entries
by SourceForge.net 21 Jul '08

21 Jul '08

Bugs item #2023949, was opened at 2008-07-21 21:10 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=2023949&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: Nobody/Anonymous (nobody) Assigned to: Hans-Christoph Steiner (eighthave) Summary: Add Path dialog won't accept/save new entries Initial Comment: When I try to enter a new path using the new dialog on osx the post window displays this: error: s/Pd-extended.app/Contents/Resources/extra/pddp: no such object On hitting apply and ok, then restarting Pd, then opening the Path dialog again, it reveals that the path hasn't saved. The only way i can do this is to enter the path via Startup dialog and entering a -path path/to/folder this is on 0.40.3 extended rc3 OS X 10.4.11 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2023949&group_…

1 0

[ pure-data-Bugs-2020998 ] [key], [keyup], [keyname] send OS-generated auto-repeats
by SourceForge.net 21 Jul '08

21 Jul '08

Bugs item #2020998, was opened at 2008-07-18 01:02 Message generated for change (Comment added) made by fbar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2020998&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody) Summary: [key], [keyup], [keyname] send OS-generated auto-repeats Initial Comment: [key], [keyup], [keyname] do not only send actual keyPress and keyRelease events. They also send OS-generated auto-repeat events, which makes these objects hard to use to detect individual key presses and releases. This wiki page describes three approaches for fixing this: http://wiki.tcl.tk/20299 ---------------------------------------------------------------------- >Comment By: Frank Barknecht (fbar) Date: 2008-07-20 20:12 Message: Logged In: YES user_id=569446 Originator: NO Oki, I think the platform differences (which are not exactly the issue you've reported originally, but related) make it reasonable to keep this as a bug. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-20 19:10 Message: Logged In: YES user_id=27104 Originator: YES This is a bug because the auto-repeat behavior is different on each platform. Not only I consider this a bug, but Miller as well: http://lists.puredata.info/pipermail/pd-dev/2004-11/003278.html I forgot to search the trackers before submitting this, but apparently, it was a feature request in the past. https://sourceforge.net/tracker/?func=detail&atid=478073&aid=1082251&group_… ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-07-19 13:40 Message: Logged In: YES user_id=569446 Originator: NO We both agree a lot here, though as Pd is a programming language, we maybe should not assume that everyone thinks like we do and even the wiki page you linked to says: "... usually autorepeated Key events are just fine, ...", so there are uses for autogenerated key events (at least, every OS has them, so somebody out there must think they are useful.) Anyway, as I still cannot see a real bug here, but instead a wish for a different behaviour of the key classes than it was implemented during the last 10 years, I hope you don't mind too much that I changed this report to be a feature request. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-18 17:45 Message: Logged In: YES user_id=27104 Originator: YES I have yet to find a time when I wanted the auto-repeat key presses. Plus the auto-repeat behaviors are completely different on each OS, so that means if you rely on that, your patch is tied to a specific platform. Lastly, it is far easier to generate the auto-repeat keys in Pd than it is to remove them. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-07-18 12:30 Message: Logged In: YES user_id=569446 Originator: NO I think, this report would be better as a Feature Request. Adding a way to the key-objects to discern between auto-generated and manual keypresses would be a nice feature, but in several use cases one actually *wants* to receive autogenerated keyboard requests as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2020998&group_…

1 0

[ pure-data-Bugs-2020998 ] [key], [keyup], [keyname] send OS-generated auto-repeats
by SourceForge.net 21 Jul '08

21 Jul '08

Bugs item #2020998, was opened at 2008-07-17 19:02 Message generated for change (Settings changed) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2020998&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody) Summary: [key], [keyup], [keyname] send OS-generated auto-repeats Initial Comment: [key], [keyup], [keyname] do not only send actual keyPress and keyRelease events. They also send OS-generated auto-repeat events, which makes these objects hard to use to detect individual key presses and releases. This wiki page describes three approaches for fixing this: http://wiki.tcl.tk/20299 ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-20 13:10 Message: Logged In: YES user_id=27104 Originator: YES This is a bug because the auto-repeat behavior is different on each platform. Not only I consider this a bug, but Miller as well: http://lists.puredata.info/pipermail/pd-dev/2004-11/003278.html I forgot to search the trackers before submitting this, but apparently, it was a feature request in the past. https://sourceforge.net/tracker/?func=detail&atid=478073&aid=1082251&group_… ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-07-19 07:40 Message: Logged In: YES user_id=569446 Originator: NO We both agree a lot here, though as Pd is a programming language, we maybe should not assume that everyone thinks like we do and even the wiki page you linked to says: "... usually autorepeated Key events are just fine, ...", so there are uses for autogenerated key events (at least, every OS has them, so somebody out there must think they are useful.) Anyway, as I still cannot see a real bug here, but instead a wish for a different behaviour of the key classes than it was implemented during the last 10 years, I hope you don't mind too much that I changed this report to be a feature request. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-18 11:45 Message: Logged In: YES user_id=27104 Originator: YES I have yet to find a time when I wanted the auto-repeat key presses. Plus the auto-repeat behaviors are completely different on each OS, so that means if you rely on that, your patch is tied to a specific platform. Lastly, it is far easier to generate the auto-repeat keys in Pd than it is to remove them. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-07-18 06:30 Message: Logged In: YES user_id=569446 Originator: NO I think, this report would be better as a Feature Request. Adding a way to the key-objects to discern between auto-generated and manual keypresses would be a nice feature, but in several use cases one actually *wants* to receive autogenerated keyboard requests as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2020998&group_…

1 0

[ pure-data-Bugs-2021648 ] zexy: configure.ac: $LDFLAGS in wrong place
by SourceForge.net 21 Jul '08

21 Jul '08

Bugs item #2021648, was opened at 2008-07-18 19:05 Message generated for change (Comment added) made by federico__ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2021648&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: Federico Ferri (federico__) Assigned to: IOhannes m zmlnig (zmoelnig) Summary: zexy: configure.ac: $LDFLAGS in wrong place Initial Comment: line 425 of configure.ac: LFLAGS=${LDFLAGS} is wrong. LDFLAGS are passed to gcc, not to ld. I have in my LDFLAGS -Wl,-O1, which make ld fail. ld should only see the -O1 option make output: i686-pc-linux-gnu-ld -shared --export-dynamic -Wl,-O1 -o zexy.pd_linux *.o -lm -lc i686-pc-linux-gnu-ld: unrecognized option '-Wl,-O1' i686-pc-linux-gnu-ld: use the --help option for usage information make: *** [zexy] Error 1 please fix. (you can fix it by making an empty LFLAGS) ---------------------------------------------------------------------- >Comment By: Federico Ferri (federico__) Date: 2008-07-21 19:08 Message: Logged In: YES user_id=1628983 Originator: YES hi IOhannes, I'm not sure what you should do; the 'GNU Coding Standards' document doesn't make mention of this (I generally look-up there things when I'm in doubt). As I explained, the $(LDFLAGS) has to be passed to gcc, not to ld. For example, if you have -Wl,--as-needed in $LDFLAGS, the ld program only wants to see --as-needed. There are two options: 1) [PROBABLY BAD] if you want to pass $LDFLAGS directly to linker, you have to turn the "-Wl,--flag1,--flag2" option into "--flag1 --flag2". I don't see a handy way to do it. 2) use gcc to do the linking. please read this excerpt from `man ld`: ------------------------------------------------------------------------------ Note---if the linker is being invoked indirectly, via a compiler driver (e.g. gcc) then all the linker command line options should be prefixed by -Wl, (or whatever is appropriate for the particular compiler driver) like this: gcc -Wl,--startgroup foo.o bar.o -Wl,--endgroup This is important, because otherwise the compiler driver program may silently drop the linker options, resulting in a bad link. ------------------------------------------------------------------------------ also, beware that using a LFLAGS in Makefile could give you weird results, since LFLAGS are the Lex-flags (that's not your case, since configure is just a shell script, but just to inform you ;) so, in my opinion, you should use $(CC) to link objects. now I'm asking to some people on IRC but still didn't get a reply. if I'll eventually get a better answer I'll add a comment here. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-21 15:29 Message: Logged In: YES user_id=564396 Originator: NO do you have any reference tpo the correct use of LFLAGS vs LDFLAGS? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2021648&group_…

1 0

Re: [PD-dev] sms pd external - design choices
by IOhannes m zmoelnig 21 Jul '08

21 Jul '08

Mathieu Bouchard wrote: > On Sat, 19 Jul 2008, Mathieu Bouchard wrote: > >> Perhaps you don't, but I do print my A_LIST atoms right fucking now >> using an object called [print], in Miller's Pd, instead of agreeing >> with things that can either crash pd or make it do something undefined >> that has nothing to do with printing the contents of the string. > > Oh. Just to clear something up: I'm not patching Miller's [print], I'm > just replacing the [print] method by a different creator in > &pd_objectmaker. you don't need any more magic to do this in Pd-0.42: as soon as your library registers the [print] class it will override the original one. personally i think this is ugly. mfgadr IOhannes

1 0

[ pure-data-Bugs-2021648 ] zexy: configure.ac: $LDFLAGS in wrong place
by SourceForge.net 21 Jul '08

21 Jul '08

Bugs item #2021648, was opened at 2008-07-18 19:05 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2021648&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: Federico Ferri (federico__) >Assigned to: IOhannes m zmlnig (zmoelnig) Summary: zexy: configure.ac: $LDFLAGS in wrong place Initial Comment: line 425 of configure.ac: LFLAGS=${LDFLAGS} is wrong. LDFLAGS are passed to gcc, not to ld. I have in my LDFLAGS -Wl,-O1, which make ld fail. ld should only see the -O1 option make output: i686-pc-linux-gnu-ld -shared --export-dynamic -Wl,-O1 -o zexy.pd_linux *.o -lm -lc i686-pc-linux-gnu-ld: unrecognized option '-Wl,-O1' i686-pc-linux-gnu-ld: use the --help option for usage information make: *** [zexy] Error 1 please fix. (you can fix it by making an empty LFLAGS) ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-21 15:29 Message: Logged In: YES user_id=564396 Originator: NO do you have any reference tpo the correct use of LFLAGS vs LDFLAGS? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2021648&group_…

1 0

[ pure-data-Bugs-2017183 ] renaming 'current' dir causes error on File->Open attem
by SourceForge.net 20 Jul '08

20 Jul '08

Bugs item #2017183, was opened at 2008-07-13 06:38 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2017183&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: frey (freynz) Assigned to: Nobody/Anonymous (nobody) Summary: renaming 'current' dir causes error on File->Open attem Initial Comment: On Pd 0.40.2 vanilla, 0.41.4-vanilla, and 0.40.3-extended, renaming the directory that Pd thinks is the 'current' directory causes subsequent attempts to call up the Open dialog to fail with the following error: bad directory "/Users/damian/2.current/rj/Track.rj" bad directory "/Users/damian/2.current/rj/Track.rj" while executing "tk_getOpenFile -defaultextension .pd -filetypes { {{pd files} {.pd}} {{max files} {.pat}}} -initialdir $pd_opendir" (procedure "menu_open" line 3) invoked from within "menu_open" (procedure "pdtk_canvas_ctrlkey" line 33) invoked from within "pdtk_canvas_ctrlkey .printout.text o 0" (command bound to event) to reproduce the error: 1. open ~/thing/wossname.pd 2. close the patch. 3. mv ~/thing ~/otherthing 4. File->Open or Ctrl-O/Splodge-O ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-20 16:03 Message: Logged In: YES user_id=27104 Originator: NO I can reproduce it on Mac OS X/Intel 10.4.11 using Pd-extended 0.40.3-extended-20080708. But there is one specific thing I had to do: It happens when opening with the File->Open or Cmd-O, but not if I double-click to launch the patch. ---------------------------------------------------------------------- Comment By: frey (freynz) Date: 2008-07-18 04:44 Message: Logged In: YES user_id=1772500 Originator: YES yeah, forgot to mention that, sorry - i'm on OSX intel ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-17 18:47 Message: Logged In: YES user_id=27104 Originator: NO This works fine for me on Ubuntu/Hardy, someone the open panel magically goes to the newly named folder. I am guessing that ext3 now has some magic to make this happen. HFS+ does this kind of thing, AFAIK. What platform did this happen for you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2017183&group_…

1 0

[ pure-data-Bugs-1982664 ] vbap freezes Pd when it receives a large float value
by SourceForge.net 19 Jul '08

19 Jul '08

Bugs item #1982664, was opened at 2008-06-02 17:14 Message generated for change (Settings changed) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1982664&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: 7 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody) >Summary: vbap freezes Pd when it receives a large float value Initial Comment: On Mac OS X 10.4.11/Intel running 0.40.3-extended-20080602, sending an 'inf' float value, then banging vbap causes pd to freeze. See attached patch for example ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1982664&group_…

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
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 July 2008