>> On Mon, 2023-06-05 at 11:46 +0200, Miller Puckette wrote:
>> Pdouble?
>
> Pd?
pdpd?
enohp ym morf tnes
-----------
Dan Wilcox
danomatika.comrobotcowboy.com
My gut feeling is that this is best kept as two separate builds for the platform. IMO we don't want to have to resort to a lot of trickery fighting the system's preferred modus operandi as it will, as you write, likely blow up in our faces.
> On Jun 12, 2023, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote:
>
> Message: 1
> Date: Mon, 12 Jun 2023 09:08:36 +0200
> From: IOhannes m zm?lnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at>>
> To: pd-dev(a)lists.iem.at &…
[View More]lt;mailto:pd-dev@lists.iem.at>
> Subject: Re: [PD-dev] double precision pd?
> Message-ID: <d02ebe17-dce6-98a3-b55c-0f923c5f79ec(a)iem.at <mailto:d02ebe17-dce6-98a3-b55c-0f923c5f79ec@iem.at>>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> 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).
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
[View Less]
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
It will work and I don't think separate apps would be needed.
The executable within the .app bundle (Contents/MacOS/Pd) is just the renamed Wish executable which calls the Tk GUI which, in turn, starts the pd core which could be either 32 or 64 bit float precision. This could be selectable via a GUI preference which would take effect on app restart. A bigger issue might be if the core is also sending 64 bit doubles to the GUI but the GUI is not set up for that, although I don't believe that is …
[View More]the case as, at that point, things are sent as stings, ie. the contents of a wide float atom.
> On Jun 9, 2023, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote:
>
> 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)
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
[View Less]
Yeah, after batting names around, I think "pd64" is the simplest even if it potentially runs into architecture naming. It's definitely true we are well past the 32 - 64 bit transition at this point anyway. If it worked for CSound it can work for us and, really, most other naming is clunky IMO. This just needs a good explanation so the usage of 64 is clear: 64-bit double precision floats and support for very long sound files (via CAF).
> On Jun 8, 2023, at 11:15 AM, pd-dev-request(a)lists.…
[View More]iem.at wrote:
>
> Message: 1
> Date: Wed, 7 Jun 2023 16:42:53 +0200
> From: IOhannes m zmoelnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at>>
> To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>
> Subject: Re: [PD-dev] double precision pd?
> Message-ID: <5cf4aa6d-c70e-8fd3-993a-e4d1b49d1f89(a)iem.at <mailto:5cf4aa6d-c70e-8fd3-993a-e4d1b49d1f89@iem.at>>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> On 6/7/23 12:55, Antoine Rousseau wrote:
>> Le mer. 7 juin 2023 ? 10:47, Lucas Cordiviola <lucarda27(a)hotmail.com <mailto:lucarda27@hotmail.com>> a
>> ?crit :
>>
>>> For me pd64 gives more chances of confusion than pdd or pdpd.
>>>
>> (...)
>>
>>> Starting with a new name of the app seems the most sane.
>>>
>>
>> Funnily, my personal feeling is the opposite :-)
>> I feel that Pd64 clearly describes Pd working with 64 bit data.
> [...]
>>
>> To me, "pdd" or "pdpd" really sound like different apps, which I find a bit
>> strange (it's actually the same app, only different options).
>
> that's also my personal feeling.
>
> double-precision Pd ist just a variant, and pdpd is hard to read (once
> you leave the Pd universe).
>
> on my system i can install "libpdl, libpdb-redo, libpda-* packages, and
> I'm not overly enthusiastic about finding a "libpdpd" in this list.
> probably the library version is not so important, so with applications
> it is: "pdal, pdd, pdf, pdl, pdb", and having a "pdpd" in there seems
> also hard to sport.
>
> my brain is just faster with keeping number (like "64" or "2") apart
> from alpha-chars...
>
>
>> I quite like Pd? or even Pd2, though.
>
> i like them too, esp the "Pd?" looks good and has a nice ring, but of
> course this is not an ASCII-compatible name and thus a no go.
>
> with Pd2, i guess people will wonder when they missed the v1.0 release
> of Pd though (something I don't see happening with Pd64).
>
>
> as a reference, the venerable Csound (which i think has been using
> double precision as the internal data representation for >10 years no),
> is (still) using csound64 (as in "csound64.dll") for the
> double-precision (even though it no longer offers any single-precision
> variant).
> afaict this is independent from "64bit architecture" (but it seems they
> no longer provide any 32bit architecture downloads (e.g. for Win32))
>
> so in the long run, i think that 32bit architectures will no longer be
> relevant on any download page (i guess the only 32bit architecture that
> will stay relevant for some time is armv8; but there are no downloadable
> binaries on any homepage anyhow; and a package manager like "apt" picks
> the "correct" version of Pd anyhow)
>
>
> i think one of the questions is, where the name will actually be exposed.
>
> - of course, the webpage (https://msp.ucsd.edu/, https://puredata.info/)
> cou use whatever descriptive name to lure the people into downloading
> the right package.
> - personally I'm mostly concerned with package managers (and as said
> above: all package managers I know of have a way to handle the
> architecture (amd64, i386) more or less transparently)
> - then there's the binary you run on your computer
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
[View Less]
Howdy all,
if we are in a release cycle, is there anything major I can look at? I’m thinking of Tk 8.6.13 for macOS builds, etc.
enohp ym morf tnes
-----------
Dan Wilcox
danomatika.comrobotcowboy.com
I agree the “64” naming, while technically correct, will just get mixed up with architecture.
Too bad “dp” is already used by pddp.
I now think of “wide” pd but that’s perhaps too general, although could be fun.
enohp ym morf tnes
-----------
Dan Wilcox
danomatika.comrobotcowboy.com
> On Jun 5, 2023, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote:
>
> Message: 3
> Date: Mon, 5 Jun 2023 11:44:54 +0200
> From: IOhannes m zm?lnig <zmoelnig(a)iem.at>
> To: pd-dev(a)…
[View More]lists.iem.at
> Subject: Re: [PD-dev] double precision pd?
> Message-ID: <0891ab25-d572-828b-881a-cef4cc65c300(a)iem.at>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
>> 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...
[View Less]
I would also suggest putting important platform-specific stuff with the sources in msw/README.txt.
> On May 19, 2023, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote:
>
> Message: 3
> Date: Fri, 19 May 2023 09:17:57 +0200
> From: Pierre Mallard <mallard.pierre(a)gmail.com <mailto:mallard.pierre@gmail.com>>
> To: Christof Ressi <info(a)christofressi.com <mailto:info@christofressi.com>>
> Cc: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>
…
[View More]> Subject: Re: [PD-dev] Compiling debug mode for GDB on MSYS2 MINGW64
> Message-ID:
> <CAKODt8xPxkv=mC9t9fU6LfY=bfOi651E55u5RoTx73tAXuEMyQ(a)mail.gmail.com <mailto:CAKODt8xPxkv=mC9t9fU6LfY=bfOi651E55u5RoTx73tAXuEMyQ@mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
>
> Hello Chris and everyone,
>
> Thanks for the trick, it could be nice to complete the wiki on
> http://puredata.info/docs/developer/BuildingPd with at least your approach
> (mine would require to patch msw/Makefile.am)
> Let me know if it is worth it, I don't have an account there.
>
> Bye
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
[View Less]