Patches item #1943614, was opened at 2008-04-16 00:25
Message generated for change (Settings changed) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1943614&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: Duplicate
Priority: 5
Private: No
Submitted By: Jakob Leben (jleben)
Assigned to: Nobody/Anonymous (nobody)
Summary: speed up 'graph on parent'
Initial Comment:
Here is the update of my patch filed as 1943301 (move instead of draw when 'graphed on parent') - now made with diff -uwB ;)
I fixed both of the bugs mentioned when I posted the first version of this patch. I noticed that one of them, namely the name of garray missing when array is created was a general bug and not produced by my code. This is now solved also, for the good of the pd community!
I also added iemgui_graph function which now all iemgui objects call as their graph_fn function and it in turn calls object's x_gui.x_draw function. This allows for graph_displace to make generic calls to graph_fn functions of all of it's children.
I would also like to point out that this patch only offers the possibility to use Tk command move for moving graphics of objects which are 'graphed on parent'. To add graph_fn functions to all the pd-vanilla objects I simply copied the code they use to draw themselves when being displaced, and currently many of them actually redraw themselves instead of just move. I paid attention that garray's graphics are really moved though, because to speed up array drawing was the main objective of writing this patch.
One problem I wish to point at is: if an object uses iemgui_displace function (and it holds the same now for new iemgui_graph function) it actually loses possibility to easily use Tk move command, because iemgui functions don't pass the dx and dy arguments to local object's functions they call for drawing. Thus using iemgui_displace and iemgui_graph makes it even less convenient and effective. I think iemgui functions should do more to make writing of gui externals easy.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-04-24 15:56
Message:
Logged In: YES
user_id=27104
Originator: NO
closed since this is replaced by #1948146
----------------------------------------------------------------------
Comment By: Jakob Leben (jleben)
Date: 2008-04-17 00:54
Message:
Logged In: YES
user_id=2064182
Originator: YES
File Added: pd-0.41-4.leben4-garrayonly.patch
----------------------------------------------------------------------
Comment By: Jakob Leben (jleben)
Date: 2008-04-17 00:53
Message:
Logged In: YES
user_id=2064182
Originator: YES
Fixed: wrong drawing of nested graphs-on-parent.
File Added: pd-0.41-4.leben4.patch
----------------------------------------------------------------------
Comment By: Jakob Leben (jleben)
Date: 2008-04-16 22:13
Message:
Logged In: YES
user_id=2064182
Originator: YES
File Added: pd-0.41-4-leben3.patch
----------------------------------------------------------------------
Comment By: Jakob Leben (jleben)
Date: 2008-04-16 22:12
Message:
Logged In: YES
user_id=2064182
Originator: YES
New fix to the patch: changing plotting style for arrays didn't work right
with the patch
A thought: with this patch, redrawing the array is reduced to one time
only after changes on the array dialog are applied. I also tweaked some
functions in g_array.c so that they produce as little redrawings as
possible. However, both garray_resize and garray_redraw produce redrawing
and they are both "public" functions (in m_pd.h). This behaviour seems
logical, but for example soundfiler object uses them both when reading a
file into the array, so that the array gets redrawn twice, which is not
good according to how CPU demanding is the plotting of arrays currently. I
have no ideas how to solve this.
File Added: pd-0.41-4-leben3-garrayonly.patch
----------------------------------------------------------------------
Comment By: Jakob Leben (jleben)
Date: 2008-04-16 14:18
Message:
Logged In: YES
user_id=2064182
Originator: YES
File Added: pd-0.41-4-leben-garrayonly.patch
----------------------------------------------------------------------
Comment By: Jakob Leben (jleben)
Date: 2008-04-16 14:17
Message:
Logged In: YES
user_id=2064182
Originator: YES
NEW FIXES:
- displacing a graph on parent when it has it's window open moves
graphical content inside this window.
- displacing nested graphs on parent doesn't work (crash)
I realized that there IS quite a lot of externals that use widget
behaviors, so I also made another patch witch only fixes slow displacing of
arrays and doesn't bring new widgetbehavior. This one can safely be used
with pd-extended.
File Added: pd-0.41-4-leben.patch
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1943614&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: 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 #1943301, was opened at 2008-04-15 15:09
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1943301&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: Duplicate
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: move instead of redraw GUI objects 'graphed on parent
Initial Comment:
New widget behavior 'graphfn' which gets called by graph_displace function and only uses Tk command 'move' to move graphics instead of erasing and recreating them.
Patch also adds graphfn functions to all the pd-vanilla GUI objects.
Also some modification inside g_array.c to remove unnecessary multiple visualizations of garrays.
Result: improved performace of array drawing.
Usage: invoke the patch inside the 'src' folder.
Known bugs that are newly introduced by this patch:
- Array name is not visible immediately after inserting an array. It gets drawn though at first redraw of the array after the array has been moved from the border of the canvas.
- Comments that are 'graphed on parent' don't move with graph. However, they are drawn at the right place when their redrawing occurs.
Fixes come soon.
Jakob Leben
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-04-24 15:56
Message:
Logged In: YES
user_id=27104
Originator: NO
closed since this is replaced by #1948146
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-04-15 18:59
Message:
Logged In: YES
user_id=27104
Originator: NO
This patch seems to include a lot of whitespace changes, making it very
hard to read. Can you recreate it in 'diff -uw' format please? :)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1943301&group_…
Bugs item #1811453, was opened at 2007-10-11 03:58
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1811453&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: Ed Kelly (edkelly)
Assigned to: IOhannes m zmölnig (zmoelnig)
Summary: msgfile cannot read files on pd extended 0.39.3 win32
Initial Comment:
msgfile on pd-extended-0.39.3 gives the following message when trying to read a file:
error: msgfile_read: unable to lseek
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2008-04-23 19:20
Message:
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2008-04-09 11:49
Message:
Logged In: YES
user_id=564396
Originator: NO
i think i have fixed this in CVS. the problem turned out to be a binary vs
text reading of the file.
pleas check whether it works (at least with Pd-ext-0.40)
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2007-10-15 01:04
Message:
Logged In: YES
user_id=564396
Originator: NO
does this problem persist when you build zexy yourself?
or with older versions of zexy? (both in pd-extended and the outdated zexy
distribution?)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1811453&group_…
Bugs item #1950095, was opened at 2008-04-23 20:39
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=1950095&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: ClaudiusMaximus (claudiusmaximus)
Assigned to: Nobody/Anonymous (nobody)
Summary: [readanysf~] incompatible with new FLAC API
Initial Comment:
It seems the FLAC API changed recently, making it impossible to compile readanysf~ on GNU/Linux Debian Lenny, and probably other systems too:
./configure && make
[snip]
ReadFlac.cpp: In member function ‘virtual bool ReadFlac::Initialize()’:
ReadFlac.cpp:80: error: ‘FLAC__stream_decoder_set_read_callback’ was not declared in this scope
ReadFlac.cpp:81: error: ‘FLAC__stream_decoder_set_write_callback’ was not declared in this scope
ReadFlac.cpp:83: error: ‘FLAC__stream_decoder_set_metadata_callback’ was not declared in this scope
ReadFlac.cpp:84: error: ‘FLAC__stream_decoder_set_error_callback’ was not declared in this scope
ReadFlac.cpp:85: error: ‘FLAC__stream_decoder_set_client_data’ was not declared in this scope
ReadFlac.cpp:87: error: ‘FLAC__stream_decoder_init’ was not declared in this scope
ReadFlac.cpp: In member function ‘void ReadFlac::ErrorCheck(int)’:
ReadFlac.cpp:273: error: ‘FLAC__STREAM_DECODER_INVALID_CALLBACK’ was not declared in this scope
make[2]: *** [ReadFlac.o] Error 1
make[2]: Leaving directory `/home/claude/src/pure-data/trunk/externals/august/readanysf~/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/claude/src/pure-data/trunk/externals/august/readanysf~'
make: *** [all] Error 2
This might have some useful tips, but I haven't the time at the moment to read it:
http://flac.sourceforge.net/api/group__porting.html
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1950095&group_…
Bugs item #1749885, was opened at 2007-07-08 05:16
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1749885&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: Works For Me
Priority: 7
Private: No
Submitted By: Frank Barknecht (fbar)
Assigned to: Nobody/Anonymous (nobody)
Summary: zl nth from cyclone crashes on lists with more than 32 items
Initial Comment:
The object [zl nth] from cyclone crashes Pd when dealing with lists of more than 32 items. See attached patch.
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2008-04-21 19:20
Message:
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2008-04-07 02:34
Message:
Logged In: YES
user_id=564396
Originator: NO
works fine here too (with self-compiled pd-0.41 and cyclone)
----------------------------------------------------------------------
Comment By: stffn (stffn)
Date: 2007-10-16 05:47
Message:
Logged In: YES
user_id=1658640
Originator: NO
I can not reproduce. Instead it works as expected.
This is Pd-extended (0.39.3) of the 13th of October 2007 autobuilds on
core due macbook running mac os x.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1749885&group_…
Bugs item #1814754, was opened at 2007-10-16 15:37
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1814754&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: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: olsen (sesselastronaut)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: libquicktime0 dependency on gutsy
Initial Comment:
depends on libquicktime0 which is not availiable for
gutsy.
hackish & evil workaround posted by IOhannes:
newer versions of debian (and therefore ubuntu) have replaced
libquicktime0 (0.9.x) by libquicktime1 (1.0.x)
most likely these are binary compatible and you could install the old
package with an override-dependencies flag.
(you might also have to symlink the /usr/lib/libquicktime.so.0 to
/usr/lib/libquicktime.so)
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2008-04-21 19:20
Message:
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: oli44 (oli44)
Date: 2008-04-07 01:24
Message:
Logged In: YES
user_id=1473188
Originator: NO
Shouldn t this bug be closed? i just installed pd-extended on a fresh
gutsy install and it looked ok
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-18 06:31
Message:
Logged In: YES
user_id=27104
Originator: NO
pdp and pidip will need to be ported to libquicktime 1.0.
----------------------------------------------------------------------
Comment By: olsen (sesselastronaut)
Date: 2007-10-17 08:12
Message:
Logged In: YES
user_id=1911773
Originator: YES
this attempt was done with Pd-0.39.3-extended-ubuntu-feisty-i386.deb of
course
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1814754&group_…
Patches item #1948287, was opened at 2008-04-21 17:50
Message generated for change (Comment added) made by radarsat1
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: Open
Resolution: None
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: 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 #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: Open
Resolution: None
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: 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_…