Patches item #3505262, was opened at 2012-03-15 07:33
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3505262&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: Fixed
Priority: 5
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: slightly increase buffers when dealing with UTF8
Initial Comment:
running Pd through valgrind [1] gives a number of "Invalid read" errors, as soon as you create an object and type a single letter (e.g. "f").
creating the object (by licking besides it), gives another number of "Invalid read" errors.
those errors suggest that memory outside the allocated buffer is accessed. it seems that all these errors are related to the UTF-8 code (since with utf-8 we might have to check multiple bytes).
the attached fix simply increases the allocated buffer slightly (more than what happens already), so the read can take place on safe grounds.
[1] like with $ valgrind --tool=memcheck --leak-check=full ./src/pd -noprefs -nrt -noaudio -stderr
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-06-22 15:19
Message:
applied to 0.43-3 test
----------------------------------------------------------------------
Comment By: Marvin Humphrey (creamygoodness)
Date: 2012-03-15 08:22
Message:
The existing UTF-8 processing code assumes that strings are NUL-terminated
and feels free to access that NUL byte beyond the buffer. However, the
strings PD uses are always paired with a length, so it is possible to
perform UTF-8 processing without going past the end of the buffer. That
other patch gets rid of the overruns, and applying it should indeed clear
the Valgrind errors that inspired both patches.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-03-15 07:47
Message:
seems like it is duplicate patches day for me:
https://sourceforge.net/tracker/?func=detail&aid=3420484&group_id=55736&ati…
i haven't really checked the other patch, but it seems like it addresses
the same issues while curing the cause rather than the symptoms.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3505262&group_…
Patches item #3518188, was opened at 2012-04-15 08:23
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3518188&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: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: support loading [classname] from classname/classname.pd
Initial Comment:
This patch adds support for loading [classname] from classname/classname.pd to match classname/classname.pd_linux support, which has been around a long time and proven quite useful. The patch adds classname/classname.pd as the last thing to try in the whole loading sequence, so it should not break anything, unless it is relying on the failure of an object to create.
One example this patch supports is the [arduino] object, which is implemented as an abstraction. With this patch, everything can be included in a folder called "arduino/" from the help patch, the meta file, and the abstraction itself. This makes installation trivial, just drop the arduino folder in the right place, and also makes the arduino folder show up in the Help Browser.
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-08-31 17:18
Message:
accepted 0.44
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3518188&group_…
Patches item #3534907, was opened at 2012-06-13 08:22
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3534907&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: None
Priority: 7
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: Pd crashes when deleting (used) array via GUI
Initial Comment:
via the properties of an array you can delete the given array (this is useful if you have multiple arrays in one graph and want to get rid of one)
unfortunately doing so can lead to a crash, if the thus-deleted array is used in a DSP-object.
the reason for this is that dsp-arrays will usually only check for the existence of a table when the dsp-graph is compiled (dsp-method), but the GUI-deletion does not trigger a re-compilation of the dsp-graph.
attached is a small example patch to trigger the problem
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-06-22 15:18
Message:
applied to 0.43-3 test
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-06-13 08:34
Message:
attached is a git-patch against current head (0.43-2) that calls
canvas_update_dsp() if the deleted array is flagged as being used in dsp
calculations.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3534907&group_…
Patches item #3536805, was opened at 2012-06-21 00:10
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3536805&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: Fixed
Priority: 7
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: [tabread4~] crashes with illegal tablesizes
Initial Comment:
as reported for the debian-package of Pd [1], pd can crash when using [tabread4~] and loading an invalid (raw) file into the table using [soundfiler].
"invalid" file means, that a (raw) file is read with a "headersize" (to skip) that is actually larger than the entire file.
[soundfiler] will attempt to resize the table to something negative (since filelength-headersize<0) which will fail safely, and leave the table at a size=1.
however, a [tabread4~] that accesses this table might segfault, since it needs more than 1 sample to interpolate.
for a patch that triggers the problem, see [1].
it seems that the problem only appears on x86_64, and not on i386.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678306
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-06-22 15:18
Message:
applied to 0.43-3test
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-06-21 00:22
Message:
attached is a patch that fixes the problem.
the patch does:
- make [soundfiler] fail if lseek(CUR)>lseek(EOF) (which is the case if the
specified header is larger than the soundfile); this is not strictly
necessary, since the array-resize will not resize to negative lengths.
- make [tabread4~] fallback to zeroes, if the table is smaller than 4
samples.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3536805&group_…
Patches item #3494768, was opened at 2012-02-26 08:10
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3494768&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: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: verbose() leaves blank lines when filtered out in Pd window
Initial Comment:
When lines are posted to the Pd window using verbose() and then the Pd window is set to display at a lower level than the verbose() posted at, the lines that were posted using verbose() will be filtered, but will leave a blank line in their place. lines posted with logpost() do not do this. For example, if I post three lines using verbose() like this:
verbose(3, "three");
verbose(4, "four");
verbose(3, "three");
Setting the log level to four will show:
three
four
three
Setting the log level to 3 will show:
three
three
When it should show:
three
three
I'm assigning this to IOhannes because I think he wrote the current verbose() function.
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-08-31 17:10
Message:
applied (0.44)
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-02-27 06:32
Message:
That was quick. The solution makes sense to me. But I think its a bad
idea to change to loglevel+4 to loglevel+3. Either leave verbose()'s
custom level numbering the same, or make it the same as the Pd window,
error(), logpost(), etc.. I still really think the +4 on the loglevel
doesn't make sense.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-02-27 04:57
Message:
attached is a fix for the problem (thus changing Tracker to 'Patches' and
assigning to miller)
it also closes the gap between verbose() and post() by applying a
loglevel-offset of '3' rather than '4' (so now verbose(0) (loglevel=3) is
following post() (loglevel=2) immediately.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-02-27 04:52
Message:
the problem comes from the use of endpost() to terminate the message.
endpost() doesn't know anything about log-levels, so it tags all LFs as
"normal".
i can think of 2 ways to fix this:
- don't use endpost() to terminate a message, but instead append the "\n"
to the message itself (which get's tagged with the log-level)
- make endpost() aware of the last used loglevel and terminate any message
using this level
i'd rather go for the 1st solution, as it doesn't require any global
state...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3494768&group_…
Patches item #3494768, was opened at 2012-02-26 08:10
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3494768&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: Pending
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: verbose() leaves blank lines when filtered out in Pd window
Initial Comment:
When lines are posted to the Pd window using verbose() and then the Pd window is set to display at a lower level than the verbose() posted at, the lines that were posted using verbose() will be filtered, but will leave a blank line in their place. lines posted with logpost() do not do this. For example, if I post three lines using verbose() like this:
verbose(3, "three");
verbose(4, "four");
verbose(3, "three");
Setting the log level to four will show:
three
four
three
Setting the log level to 3 will show:
three
three
When it should show:
three
three
I'm assigning this to IOhannes because I think he wrote the current verbose() function.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2012-10-04 02:01
Message:
very nice article and idea
http://www.cheaplouisvuittonreplica2012.com/replica-louis-vuitton-monogram-…
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-08-31 17:10
Message:
applied (0.44)
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-02-27 06:32
Message:
That was quick. The solution makes sense to me. But I think its a bad
idea to change to loglevel+4 to loglevel+3. Either leave verbose()'s
custom level numbering the same, or make it the same as the Pd window,
error(), logpost(), etc.. I still really think the +4 on the loglevel
doesn't make sense.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-02-27 04:57
Message:
attached is a fix for the problem (thus changing Tracker to 'Patches' and
assigning to miller)
it also closes the gap between verbose() and post() by applying a
loglevel-offset of '3' rather than '4' (so now verbose(0) (loglevel=3) is
following post() (loglevel=2) immediately.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-02-27 04:52
Message:
the problem comes from the use of endpost() to terminate the message.
endpost() doesn't know anything about log-levels, so it tags all LFs as
"normal".
i can think of 2 ways to fix this:
- don't use endpost() to terminate a message, but instead append the "\n"
to the message itself (which get's tagged with the log-level)
- make endpost() aware of the last used loglevel and terminate any message
using this level
i'd rather go for the 1st solution, as it doesn't require any global
state...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3494768&group_…
Bugs item #3573542, was opened at 2012-10-01 14:49
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3573542&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: v0.43
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: GUIs not updating well on parent patch
Initial Comment:
Hi there. Please check my abstraction patches as an example. I have my old PhaseVocoder patches (PhaseVoc.zip) from 2010 and a more elaborate new uptade to thos (Brane-e.zip). Both do not run well on Pd 0.43 (Vanilla or Extended).
Get the examples at:
https://docs.google.com/folder/d/0B3AoiT0xk8fnNFBxWDFNeDZ6Y1E/edit
Lets first check what happens with the PhaseVoc examples (which are 2: PVoc & LPvoc). Pvoc works fine, but LPVoc is very critical, it doesn't update well the GUI values, like number boxes or the sliders. Start recording on in and you will see. But the, it works fine on Pd 0.42
As for Brane-e, it will be the same kind of trouble when you're recording into the buffer. But i Pd 0.42 it works like a charm.
I tried other operational systems and got the same kind of problems. I'm runing a macbook air i7 1.8GHz on Mac Os 10.7.4
Cheers
Alex
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3573542&group_…
Feature Requests item #3573226, was opened at 2012-09-30 09:24
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3573226&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
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: show # of [s]/[r]'s in subpatch on subpatch
Initial Comment:
Hey,
Here is another idea..
Since pd is a graphical programing software, why not make the "wlan-cables" :) visible as well.
Personally, I tend to not use [s]/[r]'s if possible, since one (at least me) forgets, where the objects have been placed, especially if one has highly "nested" structures. ..But having nested structures is the only time when one rather needs [s]/[r]'s.
So, what's about indicating if there are [s]/[r]s somewhere inside the subpatch, on the subpatch-object or in the subpatch (on the subpatch-canvas)??
..Maybe something like a "shown-on-demand" list containing the [s]/[r]'s names.
..Or at least just a symbol (the letters "s" and/or "r" or a dot or whatever). Better than nothing!!!
PS: This sounds so easy, if I only could access some sort of savefile of a patch, without the need to save it (like in memory, or something - I'm not a hardcore-programmer) I could even analyse the file with pd itself, and draw something on the appropriate canvas via "dynamic-patching"...
Bye & I'd like to read of any resopnse... (just for the motivation)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3573226&group_…
hi all,
i would like to introduce myself and kindly request for an SVN write access
to pd repository.
My name is Antoine Villeret and i'm working with pd since i met Cyrille
Henry last year.
I'm mainly working on computer vision.
At the very beginning i'm a musician and sound technician then
I started computer vision in 2008 by turning a bodhrán into a touchscreen
during my master thesis.
After that, I worked with Cyrille on a dynamic video mapping system to
project video on moving objects on stage.
It is used in the show *Les Fuyantes *by the French circus company Les
Choses de Rien.
You can have a small overview of the the work here :
http://vimeo.com/37387879
For that work i have to add some features to pix_opencv that are already on
the repository like pix_opencv_calibration, pix_opencv_warpperspective...
(commited by Cyrille).
But i've made some others externals and also corrected lots of bugs.
I also made some examples on how to use my externals.
Moreover I've planned to develop an OpenCL based object mainly to do binary
texture readback.
And I will be happy to share my work with the community :-).
Actually i've already made a copy of the SVN repository on my github
account but it's quite experimental and only used in my personal projects.
I saw that pd, pd-extended and Gem have already migrated to git but about
externals repository ? and mainly pix_opencv ? is it planned to switch to
git too ?
My SF username is : avilleret
Kind regards
antoine
--
do it yourself
http://antoine.villeret.free.frhttp://drii.ensad.fr
--
Google lit ce mail...
si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr pour
me contacter