Bugs item #3390786, was opened at 2011-08-12 21:54
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3390786&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: v0.43
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: cant save new path entry
Initial Comment:
pd 0.43.1extended-20110812
debian squeeze 64/virtualbox host:windows7professional64
some externals are not in the path, eg pmpd. adding /usr/lib/pd-extended/extra/pmpd will work temporarily, but entry is gone on next startup.
adding to existing path separated by colon ':' behaves the same way.
this occurs both in debian and with the latest windows build.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3390786&group_…
How about turning off anonymous posting on the bug/patch/feature
trackers? The spam rate is increasing, and the anonymous bug reports
are either people who forgot to login, or otherwise quite low quality.
.hc
Begin forwarded message:
> From: "SourceForge.net" <noreply(a)sourceforge.net>
> Date: August 4, 2011 11:56:29 PM EDT
> To: "SourceForge.net" <noreply(a)sourceforge.net>
> Subject: [PD-dev] [ pure-data-Feature Requests-3386499 ]
> uftRFrmaytPSaihNksG
>
> Feature Requests item #3386499, was opened at 2011-08-05 03:56
> Message generated for change (Tracker Item Submitted) made by nobody
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3386499&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: abstractions
> Group: Next Release (example)
> Status: Open
> Priority: 5
> Private: No
> Submitted By: Nobody/Anonymous (nobody)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: uftRFrmaytPSaihNksG
>
> Initial Comment:
> 2xRW1g <a href="http://jbznfbwwzzwq.com/">jbznfbwwzzwq</a>, [url=http://jrrefggrwqmn.com/
> ]jrrefggrwqmn[/url], [link=http://hvlfkmizxyyi.com/]hvlfkmizxyyi[/
> link], http://yvlthgsufwvc.com/
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3386499&group_…
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev(a)iem.at
> http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
Patches item #3383991, was opened at 2011-08-01 19:27
Message generated for change (Tracker Item Submitted) made by jancsika1
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3383991&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
Resolution: None
Priority: 5
Private: No
Submitted By: Jonathan Wilkes (jancsika1)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix buggy editmode menu option appearance
Initial Comment:
Removes the "-selectcolor grey85" option from the "Edit Mode" checkbutton in the "Edit" menu. This was causing buggy behavior where there appears to be no checkmark until the user mouses over the "Edit Mode" option and gets a grey checkmark that is very close to the selectcolor, making it appear disabled or something.
I also removed the green background color when editmode = 1. It's unnecessary and distracting. (Though if its still wanted, I'd suggest "#c4dcdc" which is the header color for PDDP help patches, as well as the tipwindow from my tooltips patch.)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3383991&group_…
Patches item #3383901, was opened at 2011-08-01 16:21
Message generated for change (Tracker Item Submitted) made by jancsika1
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3383901&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
Resolution: None
Priority: 5
Private: No
Submitted By: Jonathan Wilkes (jancsika1)
Assigned to: Nobody/Anonymous (nobody)
Summary: word wrap in pdwindow
Initial Comment:
This patch changes the Pd window to make line breaks at word boundaries. This is more legible than the default text widget behavior, which is to break at character boundaries.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3383901&group_…
Hello,
Triggered by a recent thread (
http://lists.puredata.info/pipermail/pd-dev/2011-07/017022.html) I've
written alternative code for Pd classes like phasor~, osc~, and vcf~, in
preparation for double precision builds of Pd. These classes currently
employ Hoeldrich's method, a fascinating type punning trick for optimization
of phase-wrapping jobs. Considering available data types in C, this method
can not be translated to double precision input/output format.
Phasor~ and osc~ are typically used by the dozens in Pd setups, and even a
modest performance loss could be a show stopper for setups which are on the
limit of acceptable CPU load. Fortunately it was possible to define
double-ready versions without performance loss, by tedious elimination of
redundancy instead of fancy bit hacking. How often must a phase be wrapped?
Even at high frequencies like half the Nyquist rate, only one in four
iterations goes out of bounds. On average it proves efficient to do the
phase wrapping conditionally. Phasor~ profits most, being up to three times
faster than before, at moderate frequencies. The others did not speed up so
much, but at least none of them is slower than the original version, when
both are compared within the same Pd build. Also, the alternative versions
do not suffer from phase drift, like the Hoeldrich versions do. I have
tested this on OSX / IntelMac for single and double precision builds.
Performance may be different on other platforms / architectures. Macro
PD_BIGORSMALL was redefined to work with arbitrary precision.
A Pd running with PD_FLOATTYPE double immediately shouted at me that there's
a lot more work to do. The audio API (PortAudio in this case) couldn't
handle 64 bit output samples from dac~. Vectors are apparently read as type
float, and maximum level digital noise is the useless output. I've not
delved into this yet. Internally things seems to work well, for what I've
seen so far.
Ah, almost forgot to mention the pro's of a double precision Pd, if it will
ever work:
- indexing of large audio buffers with ample resolution for interpolation
- accurate sine and sinc of small angles, useful for things like fractional
delay
- FFT with frames larger than 2^17, I hope
- long sine sweeps without artifacts
- probably many more of such meticulous dsp jobs, you name them
If you're interested in double precision Pd, please find the attached
pd_doubletest.zip with C code and test-patches. Let me know if you have test
results on different platforms, or if you find stupid bugs in my code. Is
anyone working on other aspects of double precision Pd? I'd like to join
forces.
Katja Vetter
Bugs item #3383779, was opened at 2011-08-01 11:52
Message generated for change (Tracker Item Submitted) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3383779&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: Hans-Christoph Steiner (eighthave)
Assigned to: musil (tmusil)
Summary: iemgui lib uses 32-bit only .x%x canvas id
Initial Comment:
In order to support 64-bit environments, the canvas ID format needs to be changed from .x%x to .x%lx. This has been done throughout Pd and in most externals. iem/iemgui still has some use of the old 32-bit only .x%x. To fix, just replace .x%x with .x%lx
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3383779&group_…
Patches item #3380575, was opened at 2011-07-28 05:17
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3380575&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: Rejected
Priority: 7
Private: No
Submitted By: Chris McCormick (chr15m)
Assigned to: Miller Puckette (millerpuckette)
Summary: [makefilename] patch reliably segfaults
Initial Comment:
Attached is a patch that reliably segfaults Pd.
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-08-01 10:12
Message:
ad indentation: true, i really have to fix this once! are there any coding
guidelines available (preferrably within the pd/ directory) that explicits
the "correct" formatting?
ad confusion: hey, i just copied the original code (;-)) into a function
that can be called multiple times
anyhow, it would be good to have it fixed in _some_ way (so please do hack
on this later)
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2011-07-30 22:47
Message:
This is rather confusingly written (and badly indented)... I'd suggest
having makefilename_scanformat()
simply scan through the string in one pass. I can hack on this later if
necessary.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-07-28 12:49
Message:
attached is a patch that checks whether there are multiple format
specifiers, and if so, complains and refuses to work.
this effectively prevents the crash (though it still does not enable
multiple format specifiers)
the patch applies to todays git master.
raised priority since it is a crasher bug.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-07-28 12:46
Message:
while the docs are a bit confusion about this, [makefilename] really can
only handle a _single_ format specifier;
so using a format-string like "%s-%s" is illegal.
however, Pd should never segfault
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3380575&group_…