On 26.11.2021 17:30, Lucas Cordiviola wrote:

@porres Pd-ceammc builds Pd and their externals (for double) using default file extension.

@christof Deken is prepared for that. "vstplugin~[v0.5.3](Windows-amd64-32).dek". See the last -32 should be -64 for double.

Ah, I didn't realize! That's cool! So that part is already solved :-) This was actually my main concern.



--

Mensaje telepatico asistido por maquinas.
On 11/26/2021 1:17 PM, Christof Ressi wrote:

As I see it, one can already build FAT externals if they want to.
No, you can't. I think you're confusing this with fat binaries on macOS containing different architectures (which is not related).

At the moment, there is just no "official" strategy how to handle double precision externals. Of course, you can compile externals -DPD_FLOATSIZE=64, but how do you install them next to single precision externals? How should they be managed by Deken? These are all still open questions at the moment. There are various possible solutions, but no consensus.

On the other hand, we *could* release double precision Pd without official support for externals. I'm just not sure if this is a good idea... Personally, think we should first stabilize the API/ABI.

Christof

On 26.11.2021 17:02, Alexandre Torres Porres wrote:


Em sex., 26 de nov. de 2021 às 10:50, Christof Ressi <info@christofressi.com> escreveu:
@Lucarda Thanks for the link!

There is some more discussion in the linked issue:
https://github.com/pure-data/pure-data/issues/900

@porres As you can see, there are practical problems which need to be
solved before making it official.

I don't really get what is the issue though. As I see it, one can already build FAT externals if they want to. The fact that none (or very few) libraries are available or will be shouldn't be an actual concern as well, as I consider that this is a third party issue. If Pd Vanilla nicely fully runs in double precision, that should grant its release as a package binary out there so people can start fiddling with it, even though they're not using externals.

What I consider more proper is updating the documentation to tell the difference and also different behaviour of a particular object (specially array objects like [tabread4~]), but that can easily be done and I can take care of that. 
 
I mean, Pd-ceammc has already been shipping itself with double precision binaries and I understand they're just using vanilla's core, no code changes.

Discussions on new strategies to build external libraries can happen later and for a next release. And will probably get more traction once the double precision beast is out of the cage.

What am I missing? What doesn't make sense here?

cheers

Anyway, I think it's a good idea to start discussing this again *after*
Pd 0.52 has been released as there are still enough issues that need our
attention :-)

Christof

On 26.11.2021 13:04, Lucas Cordiviola wrote:
>
> On 11/26/2021 8:48 AM, Alexandre Torres Porres wrote:
>> Can you pinpoint the issue? what do we have to decide on externals?
>>
>> ceammc already offers a double precision download for vanilla, I
>> would also like to start providing my externals for that too
>> (cyclone/ELSE).
>>
>> What do I need to do?
>>
>> cheers
>>
>
> https://github.com/pure-data/pure-data/issues/902
>
>
> --
>
> Mensaje telepatico asistido por maquinas.
>
>
>
>
> _______________________________________________
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list



_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list