Patches item #2838176, was opened at 2009-08-15 10:56
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2838176&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tooltips patch for 0.42-5
Initial Comment:
This is GG/tim's tooltip patch ported forward to 0.42-5
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2009-08-15 12:27
Message:
It may seem like that, but I don't think its true. He is very conservative
about what he accepts. You are free to start your own branch/fork or
contribute to others if you don't like Miller's approach.
I could be convinced to include this in Pd-extended if someone was really
committed to maintaining it and handling all the issues that arise.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-15 12:23
Message:
Miller's objection about t_class is just an excuse for keeping contributors
out.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2009-08-15 12:19
Message:
Who is this mystery patch fixer? :D I would also very much like to see
tooltips in Pd, but Miller had some objections to the original version of
this patch which he outlined on the list, IIRC. Was there any attempt to
address those objections?
I think Miller's objection was related to modifying the t_class struct,
and I think Günter proposed an alternate approach that didn't need to
modify that struct.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2838176&group_…
Patches item #2838176, was opened at 2009-08-15 14:56
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2838176&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tooltips patch for 0.42-5
Initial Comment:
This is GG/tim's tooltip patch ported forward to 0.42-5
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-08-15 16:23
Message:
Miller's objection about t_class is just an excuse for keeping contributors
out.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2009-08-15 16:19
Message:
Who is this mystery patch fixer? :D I would also very much like to see
tooltips in Pd, but Miller had some objections to the original version of
this patch which he outlined on the list, IIRC. Was there any attempt to
address those objections?
I think Miller's objection was related to modifying the t_class struct,
and I think Günter proposed an alternate approach that didn't need to
modify that struct.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2838176&group_…
Patches item #2838176, was opened at 2009-08-15 10:56
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2838176&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tooltips patch for 0.42-5
Initial Comment:
This is GG/tim's tooltip patch ported forward to 0.42-5
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2009-08-15 12:19
Message:
Who is this mystery patch fixer? :D I would also very much like to see
tooltips in Pd, but Miller had some objections to the original version of
this patch which he outlined on the list, IIRC. Was there any attempt to
address those objections?
I think Miller's objection was related to modifying the t_class struct,
and I think Günter proposed an alternate approach that didn't need to
modify that struct.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2838176&group_…
Patches item #2838176, was opened at 2009-08-15 14:56
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2838176&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tooltips patch for 0.42-5
Initial Comment:
This is GG/tim's tooltip patch ported forward to 0.42-5
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2838176&group_…
Bugs item #2838114, was opened at 2009-08-15 10:33
Message generated for change (Tracker Item Submitted) made by claudiusmaximus
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2838114&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: zexy fwriteln buffer overflow
Initial Comment:
The buffer for the prefix is too small.
gcc -I. -DHAVE_CONFIG_H -DZEXY_LIBRARY -DPD -I/usr/src/pd/src -g -O2 -g -Wall -O2 -mms-bitfields -fPIC -mfpmath=sse -msse -g -O2 -g -Wall -O2 -c -o fwriteln.o fwriteln.c
In file included from /usr/include/string.h:640,
from fwriteln.c:26:
In function 'strcpy',
inlined from 'fwriteln_new' at fwriteln.c:233:
/usr/include/bits/string3.h:106: warning: call to __builtin___strcpy_chk will always overflow destination buffer
In function 'strcpy',
inlined from 'fwriteln_new' at fwriteln.c:236:
/usr/include/bits/string3.h:106: warning: call to __builtin___strcpy_chk will always overflow destination buffer
Line 195: char prefix[2]="%";
Line 233: strcpy(prefix,"%-");
Line 236: strcpy(prefix,"%+");
The strcpy will copy an additional '\0' byte which will overflow the buffer.
Suggested fix: increase the prefix buffer size
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2838114&group_…
Bugs item #2827011, was opened at 2009-07-25 09:49
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2827011&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: Duplicate
Priority: 5
Private: No
Submitted By: boonier (boonier)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: 'View List" button in Array properties not working
Initial Comment:
When clicked throws error window:
wrong # args: should be array
and has 3 btn options [OK] [Skip message] [Details]
this is on latest Pd extended 0.41.4, osx 10.4.11
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2009-08-14 11:49
Message:
This was fixed in Pd-extended 0.42, here's the bug report:
https://sourceforge.net/tracker/index.php?func=detail&aid=2807222&group_id=…
If you want, you could probably easily apply the fix to pd.tk in 0.41.4
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2827011&group_…
Bugs item #2836261, was opened at 2009-08-12 10:36
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2836261&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.42
>Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: "Find" Application Error - PD 0.42.5-extended-20090803 (XP)
Initial Comment:
using "find" from the menu or typing "ctrl+f" in PD 0.42.5-extended-20090803 (Windows XP) results in this error:
Application Error
Error: invalid command name "x"
Details:
invalid command name "x"
invalid command name "x"
while executing "x"
(procedure "find_ok" line 1)
invoked from within
"find_ok .find1"
invoked from within
".find1.button invoke"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list $w invoke]"
(procedure "tk::ButtonUp" line 24)
invoked from within
"tk::ButtonUp .find1.button"
(command bound to event)
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2009-08-14 11:34
Message:
doh, it was a stupid typo. Fixed with this commit:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=119…
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2836261&group_…
We have to sort this out!
The denormals bug in freeverb~ _seems_ to have been fixed by following Julius' advice. I made a makefile with
-fno-trapping-math
as a flag and so far so good. I haven't had a problem with the freeverb~ object pegging the CPU. May I advise that this is implemented in PD-extended, since it causes my patch to NOT WORK AT GIGS! I simply cannot take any more embarrassment. I want to play live, otherwise there's simply no point doing anything!
The second one I have discovered is in bsaylor/svf~ and there's no makefile for this in the subversion repository. I notice in the source code there is a FLUSH_TO_ZERO definition. Interestingly, when I try to compile this external using a bog-standard makefile on Ubuntu 8.10, it causes an error:
cc1: warnings being treated as errors
svf~.c: In function ‘run_svf’:
svf~.c:59: error: dereferencing type-punned pointer will break strict-aliasing rules
svf~.c:60: error: dereferencing type-punned pointer will break strict-aliasing rules
Now, I'm trying to unpick the statement:
#define FLUSH_TO_ZERO(fv) (((*(unsigned int*)&(fv))&0x7f800000)==0)?0.0f:(fv)
which is being called on lines 59 and 60 of bsaylor/svf~.c, causing the compiler to choke, and (perhaps) causing my drumsynths to break!
And by the way, where is the source code for the _other_ svf~ external?
Ed
--- On Wed, 1/7/09, Julius Smith <jos(a)ccrma.stanford.edu> wrote:
> From: Julius Smith <jos(a)ccrma.stanford.edu>
> Subject: Re: [PD] bug in freeverb???
> To: "Matt Barber" <brbrofsvl(a)gmail.com>
> Cc: pd-list(a)iem.at
> Date: Wednesday, 1 July, 2009, 8:22 PM
> Hmmm, this sounds like underflow
> traps ("denormals"). You should
> also be able to add a small constant to the input signal.
>
> I notice gcc has the option
>
> -fno-trapping-math
>
> which may make the problem disappear if my theory is
> correct. (I
> hope the FPU simply sets underflows quietly to zero when no
> trap can
> be generated.)
> There is also
>
> -ffast-math
>
> which is more aggressive.
>
> - jos
>
> At 11:30 AM 7/1/2009, Matt Barber wrote:
> >We have also had this problem, and have found that
> normally one can
> >avoid it by salting the [freeverb~] object with a
> minuscule amount of
> >noise at all times.
> >
> >Matt
> >
> >
> >
> > > Message: 5
> > > Date: Wed, 1 Jul 2009 09:57:43 -0700 (PDT)
> > > From: Andres Ferrari <anfex(a)yahoo.com>
> > > Subject: [PD] bug in freeverb???
> > > To: pd-list(a)iem.at
> > > Message-ID: <166347.29167.qm(a)web111408.mail.gq1.yahoo.com>
> > > Content-Type: text/plain; charset=iso-8859-1
> > >
> > >
> > > when is connected into freeverb any signal
> multiplied by zero
> > > the CPU usage begin to up and up to the limit,
> and if the patch
> > is heavy by far exceeds the 100%....sound and
> everything becomes a mess.
> > >
> > > This happens to me only in leopard.
> > >
> > > In osx 10.4 (ppc) and windows I've never had that
> problem.
> > > Andr?s Ferrari G.
> > >
> > > http://www.myspace.com/anfex
> > >
> >
> >_______________________________________________
> >Pd-list(a)iem.at
> mailing list
> >UNSUBSCRIBE and account-management ->
> >http://lists.puredata.info/listinfo/pd-list
>
>
> Julius O. Smith III <jos(a)ccrma.stanford.edu>
> Prof. of Music and Assoc. Prof. (by courtesy) of Electrical
> Engineering
> CCRMA, Stanford University
> http://ccrma.stanford.edu/~jos/Â
>
>
> _______________________________________________
> Pd-list(a)iem.at
> mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
Send instant messages to your online friends http://uk.messenger.yahoo.com
Bugs item #2837519, was opened at 2009-08-14 09:26
Message generated for change (Tracker Item Submitted) made by claudiusmaximus
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2837519&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: pdp mmx problems on amd64
Initial Comment:
pdp's "./configure --enable-mmx" leads to build failure on amd64:
make -C mmx
make[3]: Entering directory `/build/buildd/pd-pdp-0.12.svn20090813/system/mmx'
as -o pixel_pack_s16u8.o pixel_pack_s16u8.s
pixel_pack_s16u8.s: Assembler messages:
pixel_pack_s16u8.s:25: Error: suffix or operands invalid for `push'
pixel_pack_s16u8.s:27: Error: suffix or operands invalid for `push'
pixel_pack_s16u8.s:28: Error: suffix or operands invalid for `push'
pixel_pack_s16u8.s:73: Error: suffix or operands invalid for `pop'
pixel_pack_s16u8.s:74: Error: suffix or operands invalid for `pop'
pixel_pack_s16u8.s:82: Error: suffix or operands invalid for `push'
pixel_pack_s16u8.s:84: Error: suffix or operands invalid for `push'
pixel_pack_s16u8.s:85: Error: suffix or operands invalid for `push'
pixel_pack_s16u8.s:122: Error: suffix or operands invalid for `pop'
pixel_pack_s16u8.s:123: Error: suffix or operands invalid for `pop'
make[3]: *** [pixel_pack_s16u8.o] Error 1
it compiles fine on i386.
problem:
./configure doesn't automatically enable MMX if it is available, or disable it if requested but the CPU doesn't support it.
suggested fix:
add a test for build target CPU type in pdp/configure.ac and autoenable MMX if it is supported
suggested fix 2:
port the i386/mmx code to amd64/mmx, autoselect at compile time and/or run time
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2837519&group_…
I found a solution to the GNOME/metacity blocking the raising of
windows. It turns out to be not too bad. Basically, you just have to
'group' each window with the toplevel '.' (i.e. the Pd window), then
you can raise windows. Here's the commit for Pd-extended:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=118…
I am going to try adding this on pd-devel now...
.hc
----------------------------------------------------------------------------
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White