[L2Ork-dev] A plea for full double precision support out of the box in Purr data

[Yoann Le BORGNE]

Hi!

Intermediate user of Pd for a few years, I've been looking at Purr data 
this week and I'm quite amazed how slick it feels patching with it! 
Kudos to the devs and contributors, this is really impressive :). I'm 
writing this mail to exchange on a pretty specific feature that Pd lacks 
and to know if it could make its way into Purr data.


Double precision.


There is a clear explanation on the whereabouts of double precision 
computing in Pd here 
<http://www.katjaas.nl/doubleprecision/doubleprecision.html> 
(http://www.katjaas.nl/doubleprecision/doubleprecision.html), a video 
illustrating this point here <https://youtu.be/93632nc8LVs> 
(https://youtu.be/93632nc8LVs) and a fork of Pd extended 0.43.1 with 
full DP support here <https://github.com/pd-projects/pd-double> 
(https://github.com/pd-projects/pd-double).

An interesting quote from the first link:

While having limited effect on overall sound quality, double precision 
can still be beneficial for the quality of Pd programming in a different 
sense. Precision-robustness, combined with full numerical control from 
within the GUI, will convert Pd from a pocket calculator into a 
scientific calculator. Any user - artist or scientist - could verify 
meticulous math stuff directly in Pd, rather than bc, Octave, Grapher, 
C, or whatever inconvenient combination of these. As a computer 
language, Pd could be used for math classes and assignments at any 
level. Abstractions illustrating advanced math topics could be made. A 
wider use of Pd as a serious math language could have an impact on 
technical knowledge shared within Pd community. In my view, double 
precision could affect sound quality in particular via this detour.


On a more personal experience, I crashed at least twice on the single 
precision wall.

The first time was when I followed this serie of articles 
<http://www.earlevel.com/main/2013/06/01/envelope-generators/> 
(http://www.earlevel.com/main/2013/06/01/envelope-generators/) on 
creating an ADSR enveloppe with adjustable curve. I had to triple check 
my port of the C code following wires and boxes to then see that after a 
few math operations there were huge calculation errors.

The second time was when I found this thesis on Roland supersaw 
<https://www.nada.kth.se/utbildning/grukth/exjobb/rapportlistor/2010/rapporter10/szabo_adam_10131.pdf> 
(https://www.nada.kth.se/utbildning/grukth/exjobb/rapportlistor/2010/rapporter10/szabo_adam_10131.pdf). 
An interesting read that I couldn't implement in Pd due to rounding 
errors in computations of the equation shown p.12.


I see Purr data as a refreshing reboot of Pd trying to tackle some of 
its inherited quirks and nice-at-the-time-but-ageing-nowadays 
technological choices and couldn't resist to ask you if you could at 
least please consider this request. Seeing that Purr data intends to 
keep a K12 release, this could be a nice addition for scholar use ;)

Cheers,

Yoann

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/l2ork-dev/attachments/20170819/0bf24a1e/attachment.html>