Re: [PD-dev] call for discussion double-precision file extension

2022-03-30 Thread Sebastian Shader via Pd-dev
equ...@lists.iem.at wrote: > > Message: 1 > Date: Wed, 30 Mar 2022 16:06:23 +0200 > From: IOhannes m zmoelnig mailto:zmoel...@iem.at>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] call for discussion double-precision file >     extension &g

Re: [PD-dev] call for discussion double-precision file extension

2022-03-30 Thread Dan Wilcox
30 Mar 2022 16:06:23 +0200 > From: IOhannes m zmoelnig mailto:zmoel...@iem.at>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] call for discussion double-precision file > extension > Message-ID: <3a9d2e07-a831-eb18-7797-5ff5b191e...

Re: [PD-dev] call for discussion double-precision file extension

2022-03-30 Thread Christof Ressi
On 30.03.2022 17:40, IOhannes m zmoelnig wrote: On 3/30/22 17:21, Christof Ressi wrote: but i don't really see how it would help with fat binaries. Two solutions that come to my mind: 1) just use an ugly folder name: foo.pd/darwin-amd64-32.darwin-arm64-32/foo.dylib the problem with this

Re: [PD-dev] call for discussion double-precision file extension

2022-03-30 Thread IOhannes m zmoelnig
On 3/30/22 17:21, Christof Ressi wrote: but i don't really see how it would help with fat binaries. Two solutions that come to my mind: 1) just use an ugly folder name: foo.pd/darwin-amd64-32.darwin-arm64-32/foo.dylib the problem with this is, that it is not well-defined. currently we

Re: [PD-dev] call for discussion double-precision file extension

2022-03-30 Thread Christof Ressi
but i don't really see how it would help with fat binaries. Two solutions that come to my mind: 1) just use an ugly folder name: foo.pd/darwin-amd64-32.darwin-arm64-32/foo.dylib Typically, the user won't see it :-) 2) use a special specifier for universal binaries:

Re: [PD-dev] call for discussion double-precision file extension

2022-03-30 Thread IOhannes m zmoelnig
On 3/30/22 16:16, Christof Ressi wrote: i do not want to have zexy.darwin-amd64-32.darwin-arm64-32.so maybe a bundle structure (as described in https://lists.puredata.info/pipermail/pd-dev/2022-03/022997.html) might not be such a bad idea after all? maybe. it solves problems like

Re: [PD-dev] call for discussion double-precision file extension

2022-03-30 Thread Christof Ressi
i do not want to have zexy.darwin-amd64-32.darwin-arm64-32.so maybe a bundle structure (as described in https://lists.puredata.info/pipermail/pd-dev/2022-03/022997.html) might not be such a bad idea after all? ___ Pd-dev mailing list

Re: [PD-dev] call for discussion double-precision file extension

2022-03-30 Thread IOhannes m zmoelnig
On 3/29/22 20:03, Lucas Cordiviola wrote: Joining the discussion: I think the "deken-specifier" is Ok. here's something i just came up with: what would the deken-specifier be for fat-binaries (on macOS). i do not want to have zexy.darwin-amd64-32.darwin-arm64-32.so (the reason is

Re: [PD-dev] call for discussion double-precision file extension

2022-03-30 Thread IOhannes m zmoelnig
On 3/29/22 20:26, Sebastian Shader via Pd-dev wrote: I wonder if anything should be considered for multi-instance support as well (externals compiled w/ PDINSTANCE) good question. afaict, there are no plans to ever ship binaries Pd with PDINSTANCE=1 (but i have no idea, really). can we

Re: [PD-dev] call for discussion double-precision file extension

2022-03-29 Thread Sebastian Shader via Pd-dev
I wonder if anything should be considered for multi-instance support as well (externals compiled w/ PDINSTANCE) -seb Date: Tue, 29 Mar 2022 11:28:57 +0200 From: IOhannes m zmoelnig To: Pd-dev@lists.iem.at Subject: [PD-dev] call for discussion double-precision file extension hi, TL;DR i'd like

Re: [PD-dev] call for discussion double-precision file extension

2022-03-29 Thread Lucas Cordiviola
Joining the discussion: I think the "deken-specifier" is Ok. We should probably be prepared for both apps installations coexisting. In the case of Windows we should have a different default location and a name for the double app. Think of Pd-double whose default installation via the

Re: [PD-dev] call for discussion double-precision file extension

2022-03-29 Thread Christof Ressi
One "con" I can imagine is that there are "cleaner" alternatives than name mangling. For example, VST3 plugins use a bundle structure which also allows for "merged bundles": https://developer.steinberg.help/display/VST/Plug-in+Format+Structure. Something similar *could* work for Pd

Re: [PD-dev] call for discussion double-precision file extension

2022-03-29 Thread Roman Haefeli
On Tue, 2022-03-29 at 17:29 +0200, Christof Ressi wrote: > +1 +1 > I think it's nicer to use a common extension and have the > platform/arch/floatsize specifier as a seperate component. > > I didn't especially like this back then, but in the meantime i've > > come to the conclusion that it's

Re: [PD-dev] call for discussion double-precision file extension

2022-03-29 Thread Christof Ressi
+1 I think it's nicer to use a common extension and have the platform/arch/floatsize specifier as a seperate component. On 29.03.2022 11:28, IOhannes m zmoelnig wrote: hi, TL;DR i'd like to suggest to use deken-specifiers as (optional) part of external filenames, in order to allow

Re: [PD-dev] call for discussion double-precision file extension

2022-03-29 Thread Alexandre Torres Porres
Yeah I guess it makes sense to have a distinct extension. I haven't provided double precision externals yet because I think the binary should be easily available for those unaware of compiling magic first. And while we're at it, I guess it's time to provide them at miller's site and puredata.info

[PD-dev] call for discussion double-precision file extension

2022-03-29 Thread IOhannes m zmoelnig
hi, TL;DR i'd like to suggest to use deken-specifiers as (optional) part of external filenames, in order to allow co-installability of externals of different OSs, architectures and floatsizes (and more to come). i would really love to push the double precision saga towards a (happy) end. we