2015-11-27 9:59 GMT-02:00 katja <katjavetter@gmail.com>:
This topic keeps popping up on Pd list with stable frequency.

And I'd say I'm guilty for a few of those 
 
the price seemed to be acceptable at the time of writing (2011).

I'm aware of the writing for a few years now, and I was actually wondering/asking if by now, 2015/2016 if this move ahead was being considered.

By the way, I learned this days that Max did make this move a while ago in Max 6 (that's about 2011, btw), which was quite surprising for me.


That was before the advent of pico computers like Raspberry Pi

Exactly, I had that in mind too, but one way or another, I was thinking of a move to 64 bits as an extra (and supported/distributed) feature, but still keeping the 32 for legacy reasons and the usage in pico computers.
 
Also I realized only later that making _all_
external libs double-precision-aware is mission impossible.

well, there's a curious and relevant fact, I wonder why, but I'll just believe it.
 
double precision build is mainly valuable for evaluation. It helps finding out how important precision is for some routine, and may even provide insights which help to fix some precision issue within the constraints of single precision Pd. 

Cool, I was really curious in knowing more about all this, so I was researching again. Specially after learning that max has been 64 bits for a while, it seemed nice to evaluate what it has that Pd and SC don't.

Here's the only video I found about it anyway...

https://www.youtube.com/watch?v=QTZlWaIVjTg

It just shows about reading long buffers, that's it, and we know that... 

Seems like feedback loops in filters is something to note as relevant in 64 bit precision from what I was reading, and also from the answer I got in the SC list, which they seem to deal with internally anyway.

Sorry for insisting, but then, is that really only it?  

Since the long buffer issues have a workaround with the onset inlet in [tabread4~], that's something I'd let go. And seems like 64 bit is just too much hassle for audio processing and quality. The only issue still worth noting seems to be the quality in filters, but, what I understand here is that you couldn't "work that out internally" in Pd like they're saying they're doing in SC, right?

cheers