Pd-dev July 2010

pd-dev@lists.iem.at

20 participants
139 discussions

[ pure-data-Patches-1961878 ] add ~ and env var support to paths when opening files
by SourceForge.net 30 Jul '10

30 Jul '10

Patches item #1961878, was opened at 2008-05-11 09:28 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1961878&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: Closed Resolution: Accepted Priority: 9 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: add ~ and env var support to paths when opening files Initial Comment: Created sys_expandpath() to replace ~ with $HOME and expand env vars on Windows. This function is then used in sys_trytoopenone() so that ~ works with all opening operations. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-07-29 22:38 Message: git commits e210a2e2bba14324da3a38e5d7ac5f649082c28e c78d6b22941725368af014fd0863b00e96f0dde7 b1bbd9e0c6213986f940eb43ed0e69d926a066be ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-07-19 15:15 Message: updated using git-format-patch for 0.43.0-test1 ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-14 13:24 Message: Logged In: YES user_id=27104 Originator: YES updated to fix crasher bug on GNU/Linux File Added: add_tilde_support_toopen-0.41.4.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1961878&group_…

1 0

[ pure-data-Patches-1948287 ] Throttle speed of mouse motion events whhen moving objects.
by SourceForge.net 30 Jul '10

30 Jul '10

Patches item #1948287, was opened at 2008-04-21 17:50 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1948287&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: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Stephen Sinclair (radarsat1) Assigned to: Nobody/Anonymous (nobody) Summary: Throttle speed of mouse motion events whhen moving objects. Initial Comment: Use a clock to throttle mouse motion events when objects are being moved in the editor. This improves GUI responsiveness when moving many objects at once. Perhaps there is a better way than adding a clock instance to each and every canvas. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-07-29 22:37 Message: git commit 97247a280cfa4cf36ca4ffad4f012018401d28c2 ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2010-07-28 20:19 Message: cool - I should have done this 10 years ago. ---------------------------------------------------------------------- Comment By: Stephen Sinclair (radarsat1) Date: 2008-04-21 21:20 Message: Logged In: YES user_id=616837 Originator: YES It would probably help to use 'move', but this doesn't really conflict with that idea. Either way I think it's somewhat wasteful to redraw the screen on every mouse move event. It's only necessary to redraw as fast as: - a human can move the mouse - the screen can refresh Some tests I did with moving lots of objects (and large arrays) were much smoother using this clock. Probably one global clock could be used, since only one canvas can receive mouse motion events at a time. But that might require more complicated changes. I wasn't sure about adding the e_xnew and e_ynew variables, but I couldn't think of a better way. I'm open to ideas. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-21 19:51 Message: Logged In: YES user_id=27104 Originator: NO This in interesting idea, I think some of the IEMGUIs have built-in clocks for drawing, like [vu]. IIRC. I wonder if it would be necessary if the displace_fn stuff was cleaned up to use 'move' instead of 'delete' then 'create', like in patch #1948146. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1948287&group_…

1 0

[ pure-data-Patches-1990592 ] prevent multiple registration of loaders
by SourceForge.net 30 Jul '10

30 Jul '10

Patches item #1990592, was opened at 2008-06-11 04:30 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1990592&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: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: prevent multiple registration of loaders Initial Comment: if a single loader is registered multiple times with sys_register_loader(), it will be inserted multiple times in the loader-chain. thus it might be called several times when a new object is instantiated. i guess this could be considered a feature, but i was not able to think of any application that would need such a feature. otoh i stumbled across it, as a (rather naive) implementation of a new loader registered itself permanently, resulting in a very long list of identical loaders to be executed (yes, the bug was in my loader code, but still i think it rather weird that a loader can be registered several times) so here is a tiny patch that will prevent already registered loaders to be added to the list of loaders. --- s_loader.c (Revision 9979) +++ s_loader.c (Arbeitskopie) @@ -218,6 +218,9 @@ loader_queue_t *q = &loaders; while (1) { + /* prevent loaders from being registered multiple times */ + if (q->loader == loader) return; + if (q->next) q = q->next; else ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-07-29 22:31 Message: git commit f5a2e9e3574287a7058ff5368ac93dc11b2a3376 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1990592&group_…

1 0

Re: [PD-dev] pushes and patches
by Hans-Christoph Steiner 29 Jul '10

29 Jul '10

Speaking of callback-based audio, you might be interested in Peter Brinkmann's libpd implementation using callbacks. You can get the git here: git://gitorious.org/pdlib/pd-for-android.git then you want to look in the 'jni' folder. .hc On Wed, 2010-07-28 at 16:00 -0700, Miller Puckette wrote: > Hmm.. looks like I fumbled the first two somehow, but had taken the > third and fuorth. I don't know what happened to the first two -- I remember > applying them, go figure. > > I pushed the latest --- re-did first 2 patches, and more fooling with audio. > > cheers > Miller > > On Wed, Jul 28, 2010 at 03:05:03PM -0400, Hans-Christoph Steiner wrote: > > > > Hey Miller, > > > > I've been following your progress via git, that's super helpful. Also, > > thanks for handling the patch tracker, marking things as Accepted, etc. > > I checking out the patches as you commit them so I can make a plan for > > how to handle porting the Pd-extended code to git and the patches as you > > accepted them. For some of the patches that you recently marked as > > accepted, I can't find in the git code. As far as I could tell these > > weren't included or implemented differently: > > > > https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1242495&group_… > > https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1412469&group_… > > https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1930769&group_… > > https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2929666&group_… > > > > .hc > > > > ---------------------------------------------------------------------------- > > > > > > "[T]he greatest purveyor of violence in the world today [is] my own > > government." - Martin Luther King, Jr. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Pd-dev mailing list > > Pd-dev(a)iem.at > > http://lists.puredata.info/listinfo/pd-dev

1 0

[ pure-data-Patches-1990599 ] allow recursive calls of new_anything()
by SourceForge.net 29 Jul '10

29 Jul '10

Patches item #1990599, was opened at 2008-06-11 01:36 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1990599&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: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: allow recursive calls of new_anything() Initial Comment: currently there is a protection mechanism against recursively calling "new_anything()". unfortunately this mechanism is the main obstacle that prevents abstractions to be loaded via a "loader" mechanism (and instead requires special case handling) the attached patch will allow some recursive calling of new_anything() (but still has a protection against stack overflow, at a depth of MAXOBJDEPTH=1000) ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2010-07-28 21:00 Message: I don't remember what the problem was that required stopping recursion -- perhaps it's gone now anyway. But the check that's in the patch will keep things OK anyhow I think. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2009-03-15 17:50 Message: FYI: this was included in the Pd-extended branch in 0.40: http://lists.puredata.info/pipermail/pd-cvs/2008-06/014617.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1990599&group_…

1 0

[ pure-data-Patches-1990592 ] prevent multiple registration of loaders
by SourceForge.net 29 Jul '10

29 Jul '10

Patches item #1990592, was opened at 2008-06-11 01:30 Message generated for change (Settings changed) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1990592&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: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: prevent multiple registration of loaders Initial Comment: if a single loader is registered multiple times with sys_register_loader(), it will be inserted multiple times in the loader-chain. thus it might be called several times when a new object is instantiated. i guess this could be considered a feature, but i was not able to think of any application that would need such a feature. otoh i stumbled across it, as a (rather naive) implementation of a new loader registered itself permanently, resulting in a very long list of identical loaders to be executed (yes, the bug was in my loader code, but still i think it rather weird that a loader can be registered several times) so here is a tiny patch that will prevent already registered loaders to be added to the list of loaders. --- s_loader.c (Revision 9979) +++ s_loader.c (Arbeitskopie) @@ -218,6 +218,9 @@ loader_queue_t *q = &loaders; while (1) { + /* prevent loaders from being registered multiple times */ + if (q->loader == loader) return; + if (q->next) q = q->next; else ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1990592&group_…

1 0

[ pure-data-Patches-1981332 ] add path arg to openpanel and savepanel
by SourceForge.net 29 Jul '10

29 Jul '10

Patches item #1981332, was opened at 2008-06-01 07:38 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1981332&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: Duplicate Priority: 5 Private: No Submitted By: Martin Peach (mrpeach) Assigned to: Nobody/Anonymous (nobody) Summary: add path arg to openpanel and savepanel Initial Comment: This patch adds a path argument to openpanel and savepanel which is saved whenever the enclosing patch is saved. I used A_GIMME for the argument, but only a single symbol will be used, any other args will be quietly ignored. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2010-07-28 20:45 Message: This would make openpanel and savepanel the only two non-graphical objects to save their state in Pd -- probably we should do this either with everything in Pd (ugh) or invent something different. In fact there's no way to store a symbol non-volatilely in Pd (except using data structures, way too complicated to set up) so something else is needed. ---------------------------------------------------------------------- Comment By: Martin Peach (mrpeach) Date: 2008-06-03 06:23 Message: Logged In: YES user_id=919007 Originator: YES Not quite. My original intent was to add the ability to save and restore the current path to/from the .pd file, so I added save functions. A side effect of that is that it is now also possible to specify a path in the creation argument. A snag with that is that the displayed argument doesn't change when the current directory changes. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-06-03 00:02 Message: Logged In: YES user_id=564396 Originator: NO isn't that a dupe of: http://sourceforge.net/tracker/index.php?func=detail&aid=1244757&group_id=5… ---------------------------------------------------------------------- Comment By: Martin Peach (mrpeach) Date: 2008-06-02 10:38 Message: Logged In: YES user_id=919007 Originator: YES ...and periods of course. Part of the problem is that odd characters in filenames can get mangled by intervening software, as in the case of Pd, where you can't use { } or \ in a filename because you can't enter it, you get a message like "keycode 92: dropped" instead. ---------------------------------------------------------------------- Comment By: Martin Peach (mrpeach) Date: 2008-06-02 10:22 Message: Logged In: YES user_id=919007 Originator: YES Of course you're right. In my experience of cross-platformity though it's best to use underscores instead of spaces, never start a filename with a number, and otherwise use only alphanumeric characters in file names. It just _always_ works that way. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-06-02 10:04 Message: Logged In: YES user_id=27104 Originator: NO FYI: commas are valid in all the major filesystems, EXT2/3, HFS+, NTFS, XFS, etc. I think even FAT supports commas. Same with semi-colons. Basically, the NTFS restrictions are the common denominator (http://en.wikipedia.org/wiki/NTFS), you can't use these characters: U+0000 (NUL) / (slash) \ (backslash) : (colon) * (asterisk) ? (Question mark) " (quote) < (less than) > (greater than) and | (pipe) EXT2/3 only limits (NULL /) and HFS+ APIs limit (NULL / :) ---------------------------------------------------------------------- Comment By: Martin Peach (mrpeach) Date: 2008-06-02 09:08 Message: Logged In: YES user_id=919007 Originator: YES OK, here is a patch that just makes a path from all the arguments. If the path doesn't work it seems to be quietly ignored by tcl. Not sure which OSs allow commas in file names... File Added: panelpatch2.diff ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-06-01 15:54 Message: Logged In: YES user_id=27104 Originator: NO how about using all of the arguments as the path name? That way you can easily include paths that have spaces in them, which are quite common. you can see an example of how to convert the argv t_atom list to a binbuf then to a string here, in function print_new(): http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-extended/… Ideally, it would also handle commas, etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1981332&group_…

1 0

[ pure-data-Patches-1975056 ] show whole subpatch name in window title
by SourceForge.net 29 Jul '10

29 Jul '10

Patches item #1975056, was opened at 2008-05-27 08:18 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1975056&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: 4 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Hans-Christoph Steiner (eighthave) Summary: show whole subpatch name in window title Initial Comment: Since you can type a whole long list of atoms in the subpatch object box, it is also useful to show this whole name in the window title. This patch does that. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2010-07-28 17:49 Message: Yet another reason the bind-the-patch-to-its-name is a sucky hack that should someday be replaced with something sensible. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-06-01 02:59 Message: Logged In: YES user_id=27104 Originator: YES Oops, this patch needs some more work to better handle the receive symbol for the subpatch. I think it should just replace the spaces with dashes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1975056&group_…

1 0

[ pure-data-Patches-1963983 ] use FILENAME_MAX for all filenames, since its < MAXPDSTRING
by SourceForge.net 29 Jul '10

29 Jul '10

Patches item #1963983, was opened at 2008-05-14 10:36 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1963983&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: bugfix Status: Open Resolution: None Priority: 6 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: use FILENAME_MAX for all filenames, since its < MAXPDSTRING Initial Comment: On Windows, FILENAME_MAX is much smaller than MAXPDSTRING, so I replaced MAXPDSTRING with FILENAME_MAX everywhere I could find that is related to filenames. FILENAME_MAX is a POSIX standard macro for defining the max length of a complete filename. The current situation could result in crashes on Windows. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2010-07-28 17:47 Message: I'm not sure but I don't think Windows should have trouble trying to open files with too-long names -- if it's anything near correct it should simply refuse. And it's better to have as few POSIX dependencies as possible (Pd bios, anyone? :) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-14 10:47 Message: Logged In: YES user_id=27104 Originator: YES ok, this time really removed all bits of add_tilde_support_toopen-0.41.4.patch File Added: use_FILENAME_MAX_for_file_operations-0.41.4.patch ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-14 10:39 Message: Logged In: YES user_id=27104 Originator: YES oops, removed add_tilde_support_toopen-0.41.4.patch from this one File Added: use_FILENAME_MAX_for_file_operations-0.41.4.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1963983&group_…

1 0

[ pure-data-Patches-1948146 ] array: move instead of redraw graphics
by SourceForge.net 29 Jul '10

29 Jul '10

Patches item #1948146, was opened at 2008-04-21 11:15 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1948146&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: 5 Private: No Submitted By: Jakob Leben (jleben) Assigned to: Nobody/Anonymous (nobody) Summary: array: move instead of redraw graphics Initial Comment: This is a patch that fixes slow ("sticky") displacing of arrays by moving instead of recreating their graphics. It also fixes the problem of array name not appearing immediately after its creation as it was necessary now that arrays don't recreate but only move all that belongs to their appearance when displaced. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2010-07-28 17:41 Message: Interesting idea - I wonder though if it would be simpler and more maintainable to use some sort of throttling instead. Array moves are definitely ugly now. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-24 12:56 Message: Logged In: YES user_id=27104 Originator: NO see patches 1943614 and 1943301 for a history of this patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1948146&group_…

1 0

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 July 2010