Hey,<br><br>So after rechecking my unpacking of the tar.gz it was a user-error rather than a problem with permissions. So Katja build should work fine (does here).<br><br>Best wishes,<br><br>Julian<br><br><br><br><div class="gmail_quote">
On 25 January 2013 20:43, katja <span dir="ltr"><<a href="mailto:katjavetter@gmail.com" target="_blank">katjavetter@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sorry that must be my fault, archived it with default options. I'll<br>
have a look into that and let you know when a better .tar is uploaded.<br>
<span class="HOEnZb"><font color="#888888"><br>
Katja<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Fri, Jan 25, 2013 at 4:53 PM, Julian Brooks <<a href="mailto:jbeezez@gmail.com">jbeezez@gmail.com</a>> wrote:<br>
> Hi Katja,<br>
><br>
> Thanks for this.<br>
><br>
> When I cd into bin then ./pd I get 'permission denied'. And sudo'd I get<br>
> 'command not found'.<br>
><br>
> Any other ideas?<br>
><br>
> Jb<br>
><br>
><br>
><br>
> On 25 January 2013 15:36, katja <<a href="mailto:katjavetter@gmail.com">katjavetter@gmail.com</a>> wrote:<br>
>><br>
>> Hi Julian,<br>
>><br>
>> Most convenient is to go in the bin directory of that 'local' Pd with<br>
>><br>
>> cd /place/where/new/pd/is/bin<br>
>><br>
>> From there you can start (and restart) the local Pd with<br>
>><br>
>> ./pd<br>
>><br>
>> In my case, the recompiled Pd would not start because it could not<br>
>> find libportaudio.so.2. After installing libportaudio2 via Synaptic,<br>
>> 'normalized' Pd would finally start.<br>
>><br>
>> It is no problem to have the regular Pd still installed. Maybe you can<br>
>> install the local Pd over the regular Pd using the gnumakefile. Didn't<br>
>> try that, I don't like to install things without package manager.<br>
>><br>
>> Katja<br>
>><br>
>><br>
>><br>
>> On Fri, Jan 25, 2013 at 3:41 PM, Julian Brooks <<a href="mailto:jbeezez@gmail.com">jbeezez@gmail.com</a>> wrote:<br>
>> > Excuse my ignorance:<br>
>> > not sure how to start the below version of pd on the rpi?<br>
>> ><br>
>> > I have the full path but then what?<br>
>> ><br>
>> > if I do (in command line)<br>
>> > pd /place/where/new/pd/is/bin/pd<br>
>> > It signals watchdog.<br>
>> ><br>
>> > I also still have regular pd 0.44.0 installed btw.<br>
>> ><br>
>> > Sorry if this is dumb dumb dumb dumb Duuummmbbb.<br>
>> ><br>
>> > Jb<br>
>> ><br>
>> > On 24 January 2013 09:14, katja <<a href="mailto:katjavetter@gmail.com">katjavetter@gmail.com</a>> wrote:<br>
>> >><br>
>> >> 'Undenormalized' Pd build for Raspberry Pi is temporarily parked here<br>
>> >> for testing purposes (will be removed when Miller's release is fixed<br>
>> >> in this sense):<br>
>> >><br>
>> >> <a href="http://www.katjaas.nl/temp/pd-0.44-0-normalized.tar.gz" target="_blank">www.katjaas.nl/temp/pd-0.44-0-normalized.tar.gz</a><br>
>> >><br>
>> >> This is a locally installed Pd, like Miller's distribution. You can<br>
>> >> start it from command line with the full path to<br>
>> >> pd-0.44-0-normalized/bin/pd. It's not a .deb, so it can't be installed<br>
>> >> under supervision of package manager.<br>
>> >><br>
>> >> Katja<br>
>> >><br>
>> >><br>
>> >> On Wed, Jan 23, 2013 at 9:15 PM, Julian Brooks <<a href="mailto:jbeezez@gmail.com">jbeezez@gmail.com</a>><br>
>> >> wrote:<br>
>> >> > Hey Katja,<br>
>> >> ><br>
>> >> > Would you mind sharing the 'normalised' Pd-0.44.0 for RPi please.<br>
>> >> ><br>
>> >> > Cheers,<br>
>> >> ><br>
>> >> > Julian<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > On 23 January 2013 18:23, katja <<a href="mailto:katjavetter@gmail.com">katjavetter@gmail.com</a>> wrote:<br>
>> >> >><br>
>> >> >> Now I recompiled the Pd-0.44.0 release on Raspberry Pi (took me a<br>
>> >> >> few<br>
>> >> >> hours, not only because Pi is so slow) with PD_BIGORSMALL enabled<br>
>> >> >> for<br>
>> >> >> arm in m_pd.h. Using bigorsmalltest.pd from my previous mail I<br>
>> >> >> verified that the macro is implemented indeed.<br>
>> >> >><br>
>> >> >> Martin Brinkmann's patch chaosmonster1<br>
>> >> >> (<a href="http://www.martin-brinkmann.de" target="_blank">http://www.martin-brinkmann.de</a>) gives a beautiful illustration of<br>
>> >> >> the<br>
>> >> >> improvement. This patch is full of filters and delay lines. At it's<br>
>> >> >> initial settings, there is no subnormals problem. But if you set the<br>
>> >> >> bottom slider to the right, it gets silent. With Pd-0.44-0 release,<br>
>> >> >> CPU load explodes. With the 'normalized' Pd, nothing special<br>
>> >> >> happens.<br>
>> >> >><br>
>> >> >> And indeed, the PD_BIGORSMALL conditional checks come for free: with<br>
>> >> >> initial settings of the chaosmonster1, performance is equivalent in<br>
>> >> >> both Pd's. Cool! Hopefully this is similar on armv7.<br>
>> >> >><br>
>> >> >> Katja<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> On Wed, Jan 23, 2013 at 5:01 PM, Hans-Christoph Steiner<br>
>> >> >> <<a href="mailto:hans@at.or.at">hans@at.or.at</a>><br>
>> >> >> wrote:<br>
>> >> >> ><br>
>> >> >> > hey Katya,<br>
>> >> >> ><br>
>> >> >> > This also sounds like good evidence for your idea of writing C<br>
>> >> >> > code<br>
>> >> >> > that<br>
>> >> >> > modern compilers optimize well. Using unions for aliasing allows<br>
>> >> >> > the<br>
>> >> >> > compiler<br>
>> >> >> > to do all the new tricks, then writing loops that auto-vectorize<br>
>> >> >> > gives<br>
>> >> >> > us the<br>
>> >> >> > real benefits. Also, I think we can see some gains by using<br>
>> >> >> > memcpy()<br>
>> >> >> > since on<br>
>> >> >> > modern libc version, those are highly optimized for the given CPU,<br>
>> >> >> > dynamically<br>
>> >> >> > choosing the routines based on what instructions are available.<br>
>> >> >> > memcpy<br>
>> >> >> > will<br>
>> >> >> > use things like SSSE2 if its available.<br>
>> >> >> ><br>
>> >> >> > .hc<br>
>> >> >> ><br>
>> >> >> > On 01/23/2013 07:47 AM, katja wrote:<br>
>> >> >> >> Finally some good news on this topic. Earlier I stated that 'big<br>
>> >> >> >> or<br>
>> >> >> >> small tests' are expensive for the Pi, but that is not by<br>
>> >> >> >> definition<br>
>> >> >> >> the case. There must have been other conditions blurring my<br>
>> >> >> >> impression. I've now done a systematic test where other<br>
>> >> >> >> influences<br>
>> >> >> >> are<br>
>> >> >> >> ruled out. A test class [lopass~] with exactly the same routine<br>
>> >> >> >> as<br>
>> >> >> >> [lop~] was made, but compiled with PD_BIGORSMALL() macro enabled.<br>
>> >> >> >> It<br>
>> >> >> >> was verified that [lopass~] is not affected by denormals.<br>
>> >> >> >> Performance<br>
>> >> >> >> comparison of [lop~] and [lopass~] shows that both objects cause<br>
>> >> >> >> equivalent CPU load. Meaning, Raspberry Pi gives the 'big or<br>
>> >> >> >> small<br>
>> >> >> >> checks' for free! At least in the case of this simple filter.<br>
>> >> >> >> Please<br>
>> >> >> >> try attached bigorsmalltest.zip on the Pi to see if I'm not<br>
>> >> >> >> dreaming.<br>
>> >> >> >><br>
>> >> >> >> While I was at the topic anyway, I also tried a big or small test<br>
>> >> >> >> with<br>
>> >> >> >> union instead of direct type aliasing. It has the advantage that<br>
>> >> >> >> the<br>
>> >> >> >> compiler can apply strict aliasing rules. This test with unions<br>
>> >> >> >> did<br>
>> >> >> >> not cause extra CPU load either on the Pi. If you want to verify<br>
>> >> >> >> this<br>
>> >> >> >> result, enable the call to bigorsmall() instead of PD_BIGORSMALL<br>
>> >> >> >> in<br>
>> >> >> >> lopass~.c and recompile.<br>
>> >> >> >><br>
>> >> >> >> The fact that these tests do not cause extra CPU load, indicate<br>
>> >> >> >> that<br>
>> >> >> >> they are done in parallel with other instructions. Float and int<br>
>> >> >> >> registers are apparently strictly separated on armv6, there's no<br>
>> >> >> >> such<br>
>> >> >> >> thing like Intel's xmm registers or armv7's NEON. As it happens,<br>
>> >> >> >> the<br>
>> >> >> >> big or small tests are done on ints, aliases of the floats that<br>
>> >> >> >> must<br>
>> >> >> >> be tested. Initially I assumed that the transport of floats from<br>
>> >> >> >> vfp<br>
>> >> >> >> to the arm integer processor would be expensive, but if the<br>
>> >> >> >> instructions are done simultaneously it may be an advantage<br>
>> >> >> >> instead.<br>
>> >> >> >> Another thing is that ARM implements branch predication instead<br>
>> >> >> >> of<br>
>> >> >> >> branch prediction. Those terms look almost the same but the<br>
>> >> >> >> routines<br>
>> >> >> >> are very different. Predication is when instructions for both<br>
>> >> >> >> branches<br>
>> >> >> >> are executed, and the wrong result is simply discarded later.<br>
>> >> >> >><br>
>> >> >> >> Conclusions from the limited test with [lop~] and [lopass~] do<br>
>> >> >> >> not<br>
>> >> >> >> mean that all sorts of conditional checks are cheap on the Pi, or<br>
>> >> >> >> on<br>
>> >> >> >> ARM in general. If PD_BIGORSMALL is enabled for RPi using<br>
>> >> >> >> compile-time<br>
>> >> >> >> definition __arm__, it will also hold for armv7, but it may have<br>
>> >> >> >> very<br>
>> >> >> >> different result there. At the moment I have no access yet to an<br>
>> >> >> >> armv7<br>
>> >> >> >> device. Maybe someone can recompile test class [lopass~] and do<br>
>> >> >> >> the<br>
>> >> >> >> tests on Beagleboard or Cubieboard? Otherwise I may be able to do<br>
>> >> >> >> it<br>
>> >> >> >> on my friend's PengPod when that has arrived.<br>
>> >> >> >><br>
>> >> >> >> Katja<br>
>> >> >> >><br>
>> >> >> >><br>
>> >> >> >> On Tue, Jan 22, 2013 at 8:54 PM, Miller Puckette <<a href="mailto:msp@ucsd.edu">msp@ucsd.edu</a>><br>
>> >> >> >> wrote:<br>
>> >> >> >>> thanks - I'd better try this and find out what's going on :)<br>
>> >> >> >>><br>
>> >> >> >>> M<br>
>> >> >> >>><br>
>> >> >> >>> On Mon, Jan 21, 2013 at 11:54:29AM +0100, katja wrote:<br>
>> >> >> >>>> Tried the 0.44.0 build from your website. It has the same issue<br>
>> >> >> >>>> with<br>
>> >> >> >>>> subnormal values. My test patch is with [lop~]. If inf or nan<br>
>> >> >> >>>> is<br>
>> >> >> >>>> fed<br>
>> >> >> >>>> into [lop~], these 'values' keep circulating in the object, it<br>
>> >> >> >>>> can<br>
>> >> >> >>>> no<br>
>> >> >> >>>> longer process normal signal values.<br>
>> >> >> >>>><br>
>> >> >> >>>> I also tried my reverb stuff with specific compiler options for<br>
>> >> >> >>>> Pi's<br>
>> >> >> >>>> processor:<br>
>> >> >> >>>><br>
>> >> >> >>>> -march=armv6zk<br>
>> >> >> >>>> -mcpu=arm1176jzf-s<br>
>> >> >> >>>> -mtune=arm1176jzf-s<br>
>> >> >> >>>><br>
>> >> >> >>>> With these options, gcc should be able to decide that RunFast<br>
>> >> >> >>>> mode<br>
>> >> >> >>>> is<br>
>> >> >> >>>> permitted. But even in combination with -ffast-math (which in<br>
>> >> >> >>>> turn<br>
>> >> >> >>>> sets -funsafe-math-optimizations and -fno-trapping-math amongst<br>
>> >> >> >>>> others), denormals are still there. I'm literally out of<br>
>> >> >> >>>> options<br>
>> >> >> >>>> for<br>
>> >> >> >>>> the moment. Sorry for not having better news.<br>
>> >> >> >>>><br>
>> >> >> >>>> Katja<br>
>> >> >> >>>><br>
>> >> >> >>>><br>
>> >> >><br>
>> >> >> _______________________________________________<br>
>> >> >> <a href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
>> >> >> UNSUBSCRIBE and account-management -><br>
>> >> >> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
>> >> ><br>
>> >> ><br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br>