This may already have been discussed on the list I guess, but I wonder if there's any plan to have Pd running audio (and control) signals at 64 bit audio in the near coming future.
I know there's a version you can compile with double precision for a while now, and I'm just wondering if we should naturally expect that this will eventually happen as a default, because that is the natural course to go, or "not at all"...
One way or another, I was hoping for some explanation why it would likely and naturally go towards a 64 bit resolution or not (technical issues / pros & cons).
thanks
not much attention here, but here's an anser from the SC list about their discussion in porting the audio server to 64 bits
"The biggest advantage of higher resolution is in things like filter loops, but most SC UGens already do 64 bit calculations internally where that’s appropriate"
I guess it makes sense, 32 bit is more than enough for dealing with audio signals/amplitudes.
So I assume Pd won't likely bother to become 64 bits like Max did for similar reasons, and maybe just think "internal 64 bit calculations" sooner or later, or does that already happen?
cheers
2015-11-25 4:26 GMT-02:00 Alexandre Torres Porres porres@gmail.com:
This may already have been discussed on the list I guess, but I wonder if there's any plan to have Pd running audio (and control) signals at 64 bit audio in the near coming future.
I know there's a version you can compile with double precision for a while now, and I'm just wondering if we should naturally expect that this will eventually happen as a default, because that is the natural course to go, or "not at all"...
One way or another, I was hoping for some explanation why it would likely and naturally go towards a 64 bit resolution or not (technical issues / pros & cons).
thanks
This topic keeps popping up on Pd list with stable frequency. Here's a text about the effects of double precision in Pd:
http://www.katjaas.nl/doubleprecision/doubleprecision.html
It illustrates that double precision as Pd's basic data type will improve results for very specific cases (like reading long buffers, subsonic filtering), but it comes at a price to be payed by everyone all of the time. In terms of performance penalty, the price seemed to be acceptable at the time of writing (2011). That was before the advent of pico computers like Raspberry Pi, for which the price of doubles is much higher. Also I realized only later that making _all_ external libs double-precision-aware is mission impossible.
Since you can't mix single precision Pd with double precision externals or vice versa, you can imagine what a hairy expedition it is. As I see it now, a 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. Here's a video where you can see double precision Pd in action (in the latter part):
https://www.youtube.com/watch?v=93632nc8LVs
Katja
On Fri, Nov 27, 2015 at 5:09 AM, Alexandre Torres Porres porres@gmail.com wrote:
not much attention here, but here's an anser from the SC list about their discussion in porting the audio server to 64 bits
"The biggest advantage of higher resolution is in things like filter loops, but most SC UGens already do 64 bit calculations internally where that’s appropriate"
I guess it makes sense, 32 bit is more than enough for dealing with audio signals/amplitudes.
So I assume Pd won't likely bother to become 64 bits like Max did for similar reasons, and maybe just think "internal 64 bit calculations" sooner or later, or does that already happen?
cheers
2015-11-25 4:26 GMT-02:00 Alexandre Torres Porres porres@gmail.com:
This may already have been discussed on the list I guess, but I wonder if there's any plan to have Pd running audio (and control) signals at 64 bit audio in the near coming future.
I know there's a version you can compile with double precision for a while now, and I'm just wondering if we should naturally expect that this will eventually happen as a default, because that is the natural course to go, or "not at all"...
One way or another, I was hoping for some explanation why it would likely and naturally go towards a 64 bit resolution or not (technical issues / pros & cons).
thanks
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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
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@gmail.com:
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
You probably don't want Pd dithering behind the scenes without you knowing it. There are a couple of things to consider, though:
Dithering for 24-bit output isn't generally necessary, since most audio devices don't have true 24-bit ADC/DAC, and even with perfect equipment the noise floor is lower than the threshold of hearing given a reasonable maxamp level.
Dithering for a 16-bit audio device might be worth while, but most of these devices I've ever worked with already have more than enough analog component noise not to worry so much about truncation error.
Dithering for output to a 16-bit sound file for playback on a device with more precision is probably worth it, but you want to be able to control the kind of dither you're using, whether or not you're going to employ any noise shaping, etc. That's all stuff you can do in Pd if you want, but there are probably better (and easier!) options.
On Fri, Nov 27, 2015 at 4:00 PM, Alexandre Torres Porres porres@gmail.com wrote:
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@gmail.com:
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Precision matters a lot when using indexes, e.g. for reading large audiofiles (which can have a couple of million samples). This has been discussed a lot already in the past (also see katjaas page http://www.katjaas.nl/doubleprecision/doubleprecision.html). Miller introduced a right inlet for [tabread~] and [tabread4~] a while ago, which fixes a couple of problems, although you often have to fiddle around because you can only set it a message rate. Note, however, that [tabplay~] doesn't suffer from these problems because the indexing is handled internally.
Christof
Gesendet: Freitag, 27. November 2015 um 05:09 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "pd-lista puredata" pd-list@iem.at Betreff: Re: [PD] 64 bit audio?
not much attention here, but here's an anser from the SC list about their discussion in porting the audio server to 64 bits
"The biggest advantage of higher resolution is in things like filter loops, but most SC UGens already do 64 bit calculations internally where that’s appropriate" I guess it makes sense, 32 bit is more than enough for dealing with audio signals/amplitudes. So I assume Pd won't likely bother to become 64 bits like Max did for similar reasons, and maybe just think "internal 64 bit calculations" sooner or later, or does that already happen? cheers 2015-11-25 4:26 GMT-02:00 Alexandre Torres Porres porres@gmail.com:
This may already have been discussed on the list I guess, but I wonder if there's any plan to have Pd running audio (and control) signals at 64 bit audio in the near coming future. I know there's a version you can compile with double precision for a while now, and I'm just wondering if we should naturally expect that this will eventually happen as a default, because that is the natural course to go, or "not at all"... One way or another, I was hoping for some explanation why it would likely and naturally go towards a 64 bit resolution or not (technical issues / pros & cons). thanks _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]
haha, was too late. you already answered that one yourself :-).
Gesendet: Samstag, 28. November 2015 um 11:36 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: "Alexandre Torres Porres" porres@gmail.com Cc: "pd-lista puredata" pd-list@iem.at Betreff: Re: [PD] 64 bit audio?
Precision matters a lot when using indexes, e.g. for reading large audiofiles (which can have a couple of million samples). This has been discussed a lot already in the past (also see katjaas page http://www.katjaas.nl/doubleprecision/doubleprecision.html). Miller introduced a right inlet for [tabread~] and [tabread4~] a while ago, which fixes a couple of problems, although you often have to fiddle around because you can only set it a message rate. Note, however, that [tabplay~] doesn't suffer from these problems because the indexing is handled internally.
Christof
Gesendet: Freitag, 27. November 2015 um 05:09 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "pd-lista puredata" pd-list@iem.at Betreff: Re: [PD] 64 bit audio?
not much attention here, but here's an anser from the SC list about their discussion in porting the audio server to 64 bits
"The biggest advantage of higher resolution is in things like filter loops, but most SC UGens already do 64 bit calculations internally where that’s appropriate" I guess it makes sense, 32 bit is more than enough for dealing with audio signals/amplitudes. So I assume Pd won't likely bother to become 64 bits like Max did for similar reasons, and maybe just think "internal 64 bit calculations" sooner or later, or does that already happen? cheers 2015-11-25 4:26 GMT-02:00 Alexandre Torres Porres porres@gmail.com:
This may already have been discussed on the list I guess, but I wonder if there's any plan to have Pd running audio (and control) signals at 64 bit audio in the near coming future. I know there's a version you can compile with double precision for a while now, and I'm just wondering if we should naturally expect that this will eventually happen as a default, because that is the natural course to go, or "not at all"... One way or another, I was hoping for some explanation why it would likely and naturally go towards a 64 bit resolution or not (technical issues / pros & cons). thanks _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Christof Ressi -
katja -
Matt Barber