well, great then, cause it's been merged :) time to get ready for double precision finally then I guess! Really excited about it <3

cheers

Em sáb., 3 de jun. de 2023 às 18:38, IOhannes m zmölnig zmoelnig@iem.at escreveu:

On 6/3/23 20:02, Alexandre Torres Porres wrote:

...

Hi, with pd 0.54-0 round the corner, what is still preventing us from shipping double precision pd downloads?

from my side: https://github.com/pure-data/pure-data/pull/1605

it would be nice if this could be merged for the 0.54 release¹

in the meantime, i've instructed our CI to also produce a (signed) DMG for double-precision Pds. i'll try to also generate Windows installers for sinlge/double precision (and 32bit/64bit pointers).

so it should be straightforward for miller to publish useable files fordouble precision.

but i really think that #1605 should be applied first.

fmdsa IOhannes

PS: there's also some more of my PRs which i would like to draw special attention to (for inclusion with Pd-0.54)

• https://github.com/pure-data/pure-data/pull/1397
• https://github.com/pure-data/pure-data/pull/1590

others like #1929 or #1766 would of course be nice to have as well (as are most of my PRs ;-)) _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev

Pdouble?

On 6/5/23 11:44, IOhannes m zmölnig wrote:

On 6/4/23 17:22, Alexandre Torres Porres wrote:

...

well, great then, cause it's been merged :) time to get ready for double precision finally then I guess! Really excited about it <3

the other question that ought to answered is: how do we actually call it in order to prevent confusion?

"Pd double precision" is a bit clumsy.

"Pd64" is terser ("pd64.exe", "libpd64.dll"; and that's what I called the tentative double-precision packages for Debian/Ubuntu/... for now) but of course there might be some confusion with amd64/x86_64/arm64...

gdsaf IOhannes

---

Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev

On Mon, Jun 5, 2023, 15:27 Roman Haefeli reduzent@gmail.com wrote:

Pd²

or actually doubling it to pdpd? ... which could be read as pure double precision data.

I do prefer pd64 though despite the possible confusion - assuming that semantics for names and endings are clearly (enough) different.

PS: there's also some more of my PRs which i would like to draw special attention to (for inclusion with Pd-0.54)

To follow up, it would be great if Pd 0.54 could include my scheduler fixes/improvements:

https://github.com/pure-data/pure-data/pull/1756

It has been tested by several people on all major operating systems and I have been using it myself in production since autumn 2022.

---

Two trivial PRs:

Improve [pack] reentrancy handling: https://github.com/pure-data/pure-data/pull/1762/files

Make openpanel/savepanel dialogs window modal https://github.com/pure-data/pure-data/pull/764

---

The following PRs have been lingering for 3-4 years (!) now, although they seem rather uncontroversial and pretty useful to me.

"-open-with-args" command line option https://github.com/pure-data/pure-data/pull/1064

Clone improvements https://github.com/pure-data/pure-data/pull/1069

"goprect" message https://github.com/pure-data/pure-data/pull/627

Christof

On 03.06.2023 23:37, IOhannes m zmölnig wrote:

On 6/3/23 20:02, Alexandre Torres Porres wrote:

...

Hi, with pd 0.54-0 round the corner, what is still preventing us from shipping double precision pd downloads?

from my side: https://github.com/pure-data/pure-data/pull/1605

it would be nice if this could be merged for the 0.54 release¹

in the meantime, i've instructed our CI to also produce a (signed) DMG for double-precision Pds. i'll try to also generate Windows installers for sinlge/double precision (and 32bit/64bit pointers).

so it should be straightforward for miller to publish useable files fordouble precision.

but i really think that #1605 should be applied first.

fmdsa IOhannes

PS: there's also some more of my PRs which i would like to draw special attention to (for inclusion with Pd-0.54)

• https://github.com/pure-data/pure-data/pull/1397
• https://github.com/pure-data/pure-data/pull/1590

others like #1929 or #1766 would of course be nice to have as well (as are most of my PRs ;-))

---

Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev

How hard it would be to have both apps together in a single "Pure data" package:

$ pd

$ pd64

?

--

Mensaje telepatico asistido por maquinas.

On 07/06/2023 16:25, cyrille henry wrote:

Hello, BTW, did anyone made a benchmark : "pd double" will of course be lot's slower on 32 bit architecture, but what about 64 bit architecture? Will "pd double" perform as fast as "pd float" on modern computer? or do we need to have both version installed on the same computer? (some patch need to be fast, other need precision...)

Cheers c

Le 03/06/2023 à 20:02, Alexandre Torres Porres a écrit :

...

Hi, with pd 0.54-0 round the corner, what is still preventing us from shipping double precision pd downloads?

been waiting on it for a while now

cheers

---

Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev

---

Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev

Am 8. Juni 2023 11:15:17 MESZ schrieb Lucas Cordiviola lucarda27@hotmail.com:

How hard it would be to have both apps together in a single "Pure data" package:

Interesting idea.

Esp for the windows packages (both the zip and the installer) I think that would make a lot of sense.

For the macOS app, I don't know whether it will work (but of course the downloadable dmg could provide both apps, and it might compress well enough that the additional content won't be a problem)

On Linux I prefer to split rather than merge, so I'm pretty sure I will package them separately on Debian

$ pd

$ pd64

But if course the two packages will be co-installable. Depending on user demands, I might also consider pulling in the double-package via a "soft" dependency.

Oh no, compilation will be complex.

Not really. You basically have to build twice...

I don't think that the standard building workflow should be adjusted for the special case of building both variants (though now that I've written that, it's probably simple enough...)

mfg.sfg.jfd IOhannes

On 6/8/23 15:23, IOhannes m zmölnig wrote:

...

Oh no, compilation will be complex.

Not really. You basically have to build twice...

oh no, i forgot about the intricacies of the windows build.

with macOS and Linux we have this nice single "pd" binary (or "pd64"). but with Windows we need the supporting pd.dll library where all the guts live (so externals have something to link against), and as of now, double-precision externals on Windows will link against pd.dll as well (but expect that to be contain the double-variant).

one possible solution for this is to put the double-precision pd.exe and pd.dll into PD/bin64/ or somesuch, although this is rather ugly in the general sense, requires us to duplicate some more files in both directories and would make the Windows installation diverge from the rest of the world even more (unless we are going to duplicate the ugliness on the other systems as well).

and there are probably some pitfalls along this way...

mgfdsar IOhannes