Patches item #3438752, was opened at 2011-11-16 04:37
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3438752&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: 7
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: "pd -rt" crashes if pd-watchdog cannot be found
Initial Comment:
i'm using Pd-0.43 (today's git) on linux (debian wheezy/sid which comes with gcc-4.6.1)
if i start Pd in "realtime" mode (which is the default on linux) and it cannot find the "pd-watchdog" binary, Pd quits.
i stumbled upon this bug, since i had no link from Pd/src/ to Pd/bin/, and started Pd from it's source directory.
while i agree that my setup was somewhat broken as the pd-watchdog should have been in place, i strongly believe that Pd must not crash in these circumstances. it probably should drop realtime execution if it cannot find pd-watchdog, rather than crash.
zmoelnig@ferrari:~/src/git/pure-data$ ls bin/pd-watchdog
ls: cannot access bin/pd-watchdog: No such file or directory
zmoelnig@ferrari:~/src/git/pure-data$ ./src/pd
priority 6 scheduling enabled.
priority 8 scheduling enabled.
sh: ./bin/pd-watchdog: No such file or directory
pd: watchdog process died
zmoelnig@ferrari:~/src/git/pure-data$ pdsend errorname: >>error writing "sock8": broken pipe<<
zmoelnig@ferrari:~/src/git/pure-data$
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-06-30 14:17
Message:
There should be some way to get git to check for trailing whitespace which
I seem always
to get warned of when applying your patches...
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-03-07 05:11
Message:
i attached a small patch, that checks whether Pd can find a file named
"pd-watchdog", and if not, disabled real-time mode.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3438752&group_…
Patches item #3481846, was opened at 2012-01-30 17:41
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3481846&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: 8
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: [bugfix] on start, the Pd window doesn't always show msgs
Initial Comment:
Sometimes, when Pd starts, it only writes a portion of the stored ::pdwindow::logbuffer to the Pd Window. This tiny patch fixes that by waiting for the event loop before printing the logbuffer to the Pd window.
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-09-08 20:16
Message:
OK, I checked again and the patch made sense this time, but it's already in
the code, so closing this.
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-02-19 17:57
Message:
Hmm, the attached file doesn't look loke a patch file (some HTM trash
instead)???
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3481846&group_…
Patches item #3497084, was opened at 2012-03-05 09:41
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3497084&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-dev
Group: None
>Status: Closed
Resolution: Accepted
Priority: 7
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: fix for open_via_path() declaration headfizz
Initial Comment:
m_pd.h says that the parameters for open_via_path() are: "open_via_path(name, ext, dir, ...)"
otoh, s_path.c implements the function as "open_via_path(dir, name, ext,...)"
also the function is used as (dir, name, ext,...) throughout the code.
the attached cosmetic patch fixes the function declaration in m_pd.h, so i don't get headfizz whenever i try to find out why i'm using the function correctly.
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-08-31 17:12
Message:
done (by hand, not sure when)
----------------------------------------------------------------------
Comment By: Mathieu BOUCHARD (mathieubouchard)
Date: 2012-03-06 07:34
Message:
Just imagine that the ministry of transportation puts the wrong signs on
the autobahn. When it's time to fix them, they call the change
«cosmetic». So, of course, they ask a beautician to take care of it.
Do any changes to the docs also count as «cosmetic» ?
Because help-intro.pd always listed classes that never existed, such as
[powtorms~] and [rmstopow~]. I suppose that it's cosmetic too ?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3497084&group_…
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_…