make it double precision ready

[porres]

FFTease is also part of Pd-Ceammc, and it ships it also in double precision. Same is true for lyonpotpourri by the way

We should also make this double precision ready here then, see https://github.com/uliss/pure-data/issues/127 for reference

and I'm pinging @uliss so he can maybe help us with this process

[ericlyon]

Could you please provide a bit more context or links about 64-bit Pd? My understanding was that even up to the present, Pd externals even in 64-bit Pd run as single precision. It looks that way with the Pd internals code, the last time I checked. But I could be wrong about that. So, what exactly is being proposed here? A complete double-precision fork?

BTW, I made both LyonPotpourri and FFTease double-precision for Max/MSP 10 years ago when Max 6 came out. It's not a project I have time for right now on Pd, but anyone else who would like to do it has my blessing :)

[porres]

So, what exactly is being proposed here? A complete double-precision fork?

no

Pd can be compiled already for double precision, Pd-Ceammc is based on Vanilla 0.51-4, I think it just uses that to compil for double precision.

Now, I don't know what they did or do with fftease so it works on their distribution, they can tell us about it

but the general idea is that we just incorporate that and provide it here upstream.

It wouldn't be a fork, I guess we can make this work here with not too many changes

[Lucarda]

I don't have time right now but this boils down to:

1 - compile Pd-Double

http://msp.ucsd.edu/Pd_documentation/x6.htm#s6.6

2 - compile the lib for and against a Pd-Double

https://github.com/pure-data/pd-lib-builder/blob/master/tips-tricks.md#building-double-precision-externals

I can try and test but later.

[ericlyon]

Thank you, @porres and @Lucarda.

So here's where I'd like to learn a bit more. As of a long time ago, 64-bit Pd meant Pd compiled for 64-bit systems, but with the internal computation still done with single-precision floats. Back in 2014, I asked Miller if he had plans to upgrade the entire Pd system to 64-bit, and his response was: "yeah ... one of these days :)"

At the time, he also said this, "There are reputedly some DSP functions that misbehave when t_float is defined as double - I haven't taken the time to look into it though.

I suspect too that running on doubles would slow Pd down. Also, perhaps more troublesome, patches that were developed in 64-bit Pd might badly misbehave in 32-bit versions. Not sure what to do about that..."

Fast forward 7 years to the present. If you go to Miller's site, there's only one codebase that you can download: http://msp.ucsd.edu/software.html Currently at Pd Version 0.54-1 source

If you download that code and look at one of Pd's internals, for example, "d_osc.c", you will find that the DSP code is executed entirely with single precision floats. So, my guess is that while there may be forks that do double-precision, there's no canonical version by Miller that does double precision computation in the DSP callback routines. Happy to be proved wrong about this!

[uliss]

there are two main float types in Pd: t_float and t_sample if you define -DPD_FLOATSIZE=64 compile flag this types became double

As I see the main reason for using double precision is the lack of integer type in Pd. So if you are using [tabread~] you have float table index. This result that any table index value > 2^24+1 cannot be represented as float without error.

With SR=44100 this means that we can't use files longer than 6.3 minutes with tabread~ without errors.

[Lucarda]

@ericlyon there has been work by @umlaeute to make Pd-Double possible. I'm not sure about [osc~]. Can't tell if that particular object was left for later improvement (is one of those not really ready yet) or if the code that you are reading auto jumps to double with the pre-processor define.

[uliss]

Yes, in common case adding double support is just using t_float and t_sample types. Then build with corresponding flags and upload to deken))

[ericlyon]

Yes, in common case adding double support is just using t_float and t_sample types. Then build with corresponding flags and upload to deken))

I had another look at Miller's code. It seems that t_sample is used fairly often, but not always. Is it just a matter of replacing every t_float defined audio sample with a t_sample, or are there other complexities?

[ericlyon]

Thinking about this a bit more - even if it's just a matter of replacing t_float with t_sample for any audio sample declarations, that's still a lot of work, so there's a question of how much gain there is. AFAIK, the current FFTease/LyonPotpourri codebase works fine with Pd whether compiled for 32-bit, or for 64-bit. But I could be wrong. If any of these externals are demonstrably broken on a 64-bit build of canonical Pd, that would be a place to consider making changes to the code.

If there are no major issues, then I'm very tempted to wait until Pd switches to 64-bit only, as Max/MSP did many years ago. The transition from 32-bit to 64-bit in the Max/MSP world was a confusing and not very happy time...

[porres]

yeah, we should probably wait til Pd is officially downloadable with double precision. Right now one can compile as such, but it's still experimental.

Nonetheless, it's nice to have a heads up as it's on the way.

What I'm concerned here is that FFTease is being distributed as part of PD-CEAMMC but it is now outdated (a new release of Pd-ceammc was made yesterday and it still doesn't carry the new version, it's pre 3.0.0). Same is true for lyonpotpourri.

So when I opened the issue, they questioned about the double precision version. The thing now is that I tested it and the FFTease library they're providing in their double precision distribution of Pd-ceammc doesnt' seem to work... see https://github.com/uliss/pure-data/issues/127#issuecomment-811562610

and also this screenshot

[Lucarda]

Nonetheless, it's nice to have a heads up as it's on the way.

I had tested fftease-3.0.1 on a Debian10 live usb stick running Pd-0.51-4 Double and only came to trouble on disarrain~help.pd.

I just opened all help patches with DSP on. Not really moving any slider or listening to anything, just opening the patches.

I got this on the terminal giving some clue about [disarrain~] crashes.

[ericlyon]

Thank you, @porres. That is interesting, but FFTease loads and runs correctly on canonical 64-bit compiled Pd. As a matter of policy, I think my projects need to stick to supporting canonical Pd, and not chase after forks that are not fully compatible with canonical Pd. That being said, the CEAMMC fork looks great, and I wish its creators every success. If they want to include FFTease and LyonPotpourri in CEAMMC, two obvious solutions for them would be:

1) Figure out a way to allow 32-bit externals to load, similar to 64-bit Pd 2) Make an entirely new fork of FFTease and LyonPotpourri for use in CEAMMC

Regarding solution 2, someone actually did that for FFTease on pd-extended many years ago.

[ericlyon]

Nonetheless, it's nice to have a heads up as it's on the way.

I had tested fftease-3.0.1 on a Debian10 live usb stick running Pd-0.51-4 Double and only came to trouble on disarrain~help.pd.

I just opened all help patches with DSP on. Not really moving any slider or listening to anything, just opening the patches.

I got this on the terminal giving some clue about [disarrain~] crashes.

I could not reproduce this on macOS 64-bit Pd, though as we know Macs can be more lenient about memory errors. This looks like it might be a bug, rather than a 32/64 bit issue. (Or maybe it's both...) Would you mind moving this to a separate issue for further diagnosis?

Thanks!

[porres]

Thank you, @porres. That is interesting, but FFTease loads and runs correctly on canonical 64-bit compiled Pd. As a matter of policy, I think my projects need to stick to supporting canonical Pd, and not chase after forks that are not fully compatible with canonical Pd. That being said, the CEAMMC fork looks great, and I wish its creators every success. If they want to include FFTease and LyonPotpourri in CEAMMC, two obvious solutions for them would be:

What I like about Pd-Ceammc is that it is in fact fully compatible to Pd Vanilla. It just offers two options, the single and the double precision. For the single precision version, it is fully compatible and compliiant to the latest Pd Vanilla (0.51-4)! This means one can get FFTease direclty from deken inside Pd-Ceammc (cause it also has 'deken').

When I opened the issue on the Pd-ceammc repository, I made two remarks, one is that it's carrying an outdated version and the other is that one can just get the latest FFTease from deken, so Pd-ceammc doesn't need to bother and distribute it.

Then they asked about the double precision. But as I see, they're not distributing a version that works on their double precision variant...

The double precision variant is just Pd compiled for double precision and we can do this already for the canonical Pd Vanilla version. I get it that we don't need to bother until this is 100% for Pd Vanilla, meaning that Vanilla is also provided with double precision. I also agree that if they want to anticipate this, they can make a fork and solve the issues. That'd be great cause we can just incorporate that when Vanilla double precision is fully real.

Anyway, I can close and reopen when double precision Pd actually happens (I'd hope it could happen for 0.52, but maybe that's just too optimistic)

[porres]

Even though I closed this and can see it's not a priority, it's something on the horizon, and maybe you can continue discussing what's on the way... (maybe I should just repen this? what do you think?)

[porres]

btw, for reference https://lists.puredata.info/pipermail/pd-list/2020-11/128513.html

[ericlyon]

Thanks for all the info. Let's keep this closed. Until we have a fully committed canonical 64-bit Pd, we're just guessing that we know what will be needed to make third party externals compliant.

[umlaeute]

we do have a fully committed 64bit Pd.

what we miss is a released version of double-precision Pd (and this is what is important for this issue).

let's not confuse the both, they are unrelated.