[PD] 64 bit audio?

[Alexandre Torres Porres]

What about "dithering" or whatever... when Pd sends a 32 bit (or even 64
bit) how is it handled and reduced to 16 bits or 24 bits according to the
soundcard?

Is it up to Pd or not? One case or another, how is it done?

thanks

2015-11-27 14:19 GMT-02:00 Alexandre Torres Porres <porres at gmail.com>:

>
>
> 2015-11-27 9:59 GMT-02:00 katja <katjavetter at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151127/8dbcf462/attachment-0001.html>