Patches item #1242495, was opened at 2005-07-21 14:07
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1242495&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: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: changing properties doesn't set "modified" status
Initial Comment:
When you change the properties of an object, it does
not set the "dirty" or "modified" flag on the patch.
Therefore, Pd does not prompt to save if that patch is
closed and those changes are lost.
To see this bug in action, make a new patch, and place
a GUI bang object on the canvas (i.e. [bng]), then save
the file. Now, open the properties dialog of that bang
and change the color of it and it OK. When you close
the patch, it does not prompt you to save your changes.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2010-07-29 22:50
Message:
git commit 9f945f0121c99d2fac419475c764c4163f8c8f67
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-04-28 11:34
Message:
Logged In: YES
user_id=27104
Originator: YES
Attached is a patch that fixes this for all canvas-related properties
panels (i.e. NOT the audio/midi/path/startup pref panels). This should
work for adding and deleting cords, and properties panels for: canvas,
arrays, iemguis, and atom boxes.
The only downside is that with the properties panels, there is no checking
whether there has actually be any change. I just sets the dirty flag if
the user clicks on OK or Apply.
File Added: cords_and_properties_set_dirty-0.41.4.patch
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2007-05-27 11:08
Message:
Logged In: YES
user_id=1709568
Originator: NO
Not only changing properties of an object.
Also deleting an existing connection does not set the modified flag!
To see the bug in action:
Make a new patch, create any two objects and connect them in any way (any
inlet of one to any outlet of the other), then save the file.
Now, click on the wire connection and delete it, without moving the
objects.
When you close the patch, it does not prompt you to save your changes.
This is true both for control and signal connections.
At least Windows XP, version 0.40-2
Should I post this as a separate bug?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1242495&group_…
Patches item #1990599, was opened at 2008-06-11 04:36
Message generated for change (Comment added) made by eighthave
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: Hans-Christoph Steiner (eighthave)
Date: 2010-07-29 22:47
Message:
git commit 5a58ca2b41d9cf46a91c8897754b196582c7ca89
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2010-07-29 00: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 20: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_…
Patches item #1948146, was opened at 2008-04-21 14:15
Message generated for change (Comment added) made by eighthave
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: Hans-Christoph Steiner (eighthave)
Date: 2010-07-29 22:42
Message:
array moves should really use the tcl 'move' command. It will greatly
speed things up, IMHO. Right now, changes in arrays can generate up to 1
megabyte of Tcl code per second for the GUI to execute. Using a move
command, we should be able to get that down to a much smaller amount, I
think three or four orders of magnitude is feasible.
That said, I have not tested this patch.
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2010-07-28 20: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 15: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_…
Patches item #1962700, was opened at 2008-05-12 19:18
Message generated for change (Settings changed) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1962700&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: Rejected
Priority: 5
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: two embedded prefs for Mac: default and override all
Initial Comment:
This patch creates two different kinds of embedded org.puredata.pd.plist prefs files on Mac OS X. The first is the default settings that come with Pd-extended.app, the second is a prefs file that overrides all others, so that people can make their own custom apps based on the Pd.app, and be sure that the user's prefs aren't going to override things.
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2010-07-28 20:38
Message:
I think we should fix the preferences system so that pd extended doesn't
rely on any preferences at all -- anything short of that will make for
maintenance headaches later on.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-13 13:06
Message:
Logged In: YES
user_id=27104
Originator: YES
That could work. I don't think this will cover every possibility. I
think a more straightforward approach would be to handle very special
hardware setups in the patch rather than the preferences. I think the
preferences should be general things, since you can't really query or test
for failures with the preferences system.
For the built-in audio, it almost always just works, so specific
configuration isn't needed.
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-05-13 03:37
Message:
Logged In: YES
user_id=564396
Originator: NO
hmm, but how should the author of a custom app know about the
hardware-settings of the end-user?
wouldn't it be better to split the configuration files into
machine-dependencies (soundcard,...) and user-dependencies (libs,...) which
could then be overridden seperately?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1962700&group_…
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_…
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_…
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_…
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
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_…
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_…