'Undenormalized' Pd build for Raspberry Pi is temporarily parked here
for testing purposes (will be removed when Miller's release is fixed
in this sense):
www.katjaas.nl/temp/pd-0.44-0-normalized.tar.gz
This is a locally installed Pd, like Miller's distribution. You can
start it from command
On Wed, Jan 23, 2013 at 8:00 PM, padawa...@obiwannabe.co.uk
padawa...@obiwannabe.co.uk wrote:
On 23 January 2013 at 18:23 katja katjavet...@gmail.com wrote:
Now I recompiled the Pd-0.44.0 release on Raspberry Pi (took me a few
hours, not only because Pi is so slow)
Have you looked into cross
Thank you.
On 24 January 2013 09:14, katja katjavet...@gmail.com wrote:
'Undenormalized' Pd build for Raspberry Pi is temporarily parked here
for testing purposes (will be removed when Miller's release is fixed
in this sense):
www.katjaas.nl/temp/pd-0.44-0-normalized.tar.gz
This is a
On 01/24/2013 04:56 AM, katja wrote:
On Wed, Jan 23, 2013 at 8:00 PM, padawa...@obiwannabe.co.uk
padawa...@obiwannabe.co.uk wrote:
On 23 January 2013 at 18:23 katja katjavet...@gmail.com wrote:
Now I recompiled the Pd-0.44.0 release on Raspberry Pi (took me a few
hours, not only because Pi
On 01/24/2013 01:33 PM, padawa...@obiwannabe.co.uk wrote:
On 24 January 2013 at 17:18 Hans-Christoph Steiner h...@at.or.at wrote:
On 01/24/2013 04:56 AM, katja wrote:
On Wed, Jan 23, 2013 at 8:00 PM, padawa...@obiwannabe.co.uk
padawa...@obiwannabe.co.uk wrote:
On 23 January 2013 at 18:23
hey Katya,
This also sounds like good evidence for your idea of writing C code that
modern compilers optimize well. Using unions for aliasing allows the compiler
to do all the new tricks, then writing loops that auto-vectorize gives us the
real benefits. Also, I think we can see some gains by
Now I recompiled the Pd-0.44.0 release on Raspberry Pi (took me a few
hours, not only because Pi is so slow) with PD_BIGORSMALL enabled for
arm in m_pd.h. Using bigorsmalltest.pd from my previous mail I
verified that the macro is implemented indeed.
Martin Brinkmann's patch chaosmonster1
Hey Katja,
Would you mind sharing the 'normalised' Pd-0.44.0 for RPi please.
Cheers,
Julian
On 23 January 2013 18:23, katja katjavet...@gmail.com wrote:
Now I recompiled the Pd-0.44.0 release on Raspberry Pi (took me a few
hours, not only because Pi is so slow) with PD_BIGORSMALL enabled
Hey Pierre,
I've commented patch denorm-test.pd in such a way that it explains the
topic a bit more (see attached). Now I'd like to ask you, if you can
run the patch on a 'normal' computer and on your Raspberry Pi for
comparison. If you have Pd gui on the Pi, you should be able to check
if your
Hi Katja,
I tried on my laptop (Intel dual-core 2 duo, 1,66GHz), and it works fine I
guess. It takes a little to go from 0 to 1 and back, but there doesn't seem
to be any particular issues with NAN and INF numbers.
Now on the Pi : sending a NAN to the lop~ makes it hang. Sending 1 works
fine,
thanks - I'd better try this and find out what's going on :)
M
On Mon, Jan 21, 2013 at 11:54:29AM +0100, katja wrote:
Tried the 0.44.0 build from your website. It has the same issue with
subnormal values. My test patch is with [lop~]. If inf or nan is fed
into [lop~], these 'values' keep
Tried the 0.44.0 build from your website. It has the same issue with
subnormal values. My test patch is with [lop~]. If inf or nan is fed
into [lop~], these 'values' keep circulating in the object, it can no
longer process normal signal values.
I also tried my reverb stuff with specific compiler
Pierre, the way how denormals can impact performance on the Pi, is
whenever a an object with feedback delay (IIR filter, reverb etc.)
stops receiving input signal, it's values decay into the subnormal
range, which causes substantial increase of CPU load. Such situations
can be avoided by adding a
Hi Katja, thank you for your reply! It is now (slightly) clearer. Every
time you post something here I feel like some messages from a technical
NASA mailing list are being accidentally sent to pd-list!
Cheers,
Pierre.
2013/1/21 katja katjavet...@gmail.com
Pierre, the way how denormals can
I think this is what you want, from 'man gcc'. Its interesting to note that
the NEON mode, which provides SIMD, also does not do denormals:
-mfpu=name
-mfpe=number
-mfp=number
This specifies what floating point hardware (or hardware emulation) is
available on the target. Permissible
Hi all...
I think it's possible to get flush-to-zero behavior on the Pi (ARMv6) by
calling gcc with --fast-math. At any rate what I found was that, if I
compiled without --fast-math, when numbers got small (e.g., when a
reverberator decays down past 10^-38 or so), the patch would suddenly jump
Miller, the vanilla Pd which can be installed from Raspbian with
apt-get or Synaptic does have the subnormals problem, as can be
checked with a test patch attached with my first post. When an input
signal to [lop~] is shut off, CPU load increases substantially. Output
values go down in the order
Hans, the info about NEON is relevant for armv7 (Beagleboard,
Cubieboard, PengPod...). But Raspberry Pi doesn't have NEON. Float
processing is done on coprocessor vfpv2. As far as I can see, vfpv2
hardly has any SIMD instructions (except for moving data between ARM
and vfp). It is said to process
OK.. but try the 0.44 build on my site - the one from Raspian is quite old :)
M
On Sun, Jan 20, 2013 at 09:28:30PM +0100, katja wrote:
Miller, the vanilla Pd which can be installed from Raspbian with
apt-get or Synaptic does have the subnormals problem, as can be
checked with a test patch
19 matches
Mail list logo
