again the same question, with 0.52 around the corner, will we have a Pd double precision binary distributed?
cheers
nothing against a pre compiled binary, but considering that even i am able to roll that for myself, i wonder if thats really necessary. with the right tools installed (explained in install.txt) , i use this: cd path/to/pd ./autogen.sh ./configure CPPFLAGS="-DPD_FLOATSIZE=64" make make app
and bingo.
Am 26.11.2021 um 05:19 schrieb Alexandre Torres Porres porres@gmail.com:
again the same question, with 0.52 around the corner, will we have a Pd double precision binary distributed?
cheers _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em sex., 26 de nov. de 2021 às 05:56, hans w. koch hansw.koch@gmail.com escreveu:
nothing against a pre compiled binary, but considering that even i am able to roll that for myself, i wonder if thats really necessary.
it is :)
I think before we start supporting double precision Pd "officially", there are still a few things to sort out, particulary how to deal with externals. This has been discussed a few times on the list, but there is no real consensus yet. So I think for Pd 0.52 it's too early.
On 26.11.2021 11:19, Alexandre Torres Porres wrote:
Em sex., 26 de nov. de 2021 às 05:56, hans w. koch hansw.koch@gmail.com escreveu:
nothing against a pre compiled binary, but considering that even i am able to roll that for myself, i wonder if thats really necessary.
it is :)
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
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
Em sex., 26 de nov. de 2021 às 07:50, Christof Ressi info@christofressi.com escreveu:
I think before we start supporting double precision Pd "officially", there are still a few things to sort out, particulary how to deal with externals. This has been discussed a few times on the list, but there is no real consensus yet. So I think for Pd 0.52 it's too early. On 26.11.2021 11:19, Alexandre Torres Porres wrote:
Em sex., 26 de nov. de 2021 às 05:56, hans w. koch hansw.koch@gmail.com escreveu:
nothing against a pre compiled binary, but considering that even i am able to roll that for myself, i wonder if thats really necessary.
it is :)
_______________________________________________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
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.
@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.
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
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
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
Em sex., 26 de nov. de 2021 às 13:19, Christof Ressi info@christofressi.com escreveu:
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...
That seems harmless to me. I remember when the first 64 bit builds of Pd came around and there were no or not many externals for it. If we clearly state that there's no official support, we wash our hands. Power users can work with externals at their own risk, but regular users who don't know how to compile Pd can start benefiting from the distribution with vanilla only patches.
By the way, I can confirm compiling double precision here on mac was smooth (I have all the tools). I can also confirm deken can see and download the proper ceammc library binary. Regular users should also be aware that even those externals they can easily get by now aren't using an official and stable API.
But when that gets stronger and stabilized, nothing will change for them as developers can and should update the provided builds in deken if needed.
By the way, the way things are. What am I risking in getting ceammc from deken in my double precision build?
cheers
@porres Pd-ceammc builds Pd and their externals (for double) using default file extension.
@christof Deken is prepared for that. "vstplugin~v0.5.3.dek". See the last -32 should be -64 for double.
--
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
Em sex., 26 de nov. de 2021 às 13:33, Lucas Cordiviola < lucarda27@hotmail.com> escreveu:
@porres Pd-ceammc builds Pd and their externals (for double) using default file extension.
@christof Deken is prepared for that. "vstplugin~v0.5.3.dek". See the last -32 should be -64 for double.
yup, ceammc shows up as "Darwin-amd64-64" for me here, and the binary is "ceammc.d_amd64"
--
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
What am I risking in getting ceammc from deken in my double precision build?
Nothing. Perhaps it overwrites you single precision ceammc folder. If precision does not match Pd refuse to load (IIRC).
--
Mensaje telepatico asistido por maquinas.
On 11/26/2021 1:36 PM, Alexandre Torres Porres wrote:
Em sex., 26 de nov. de 2021 às 13:33, Lucas Cordiviola lucarda27@hotmail.com escreveu:
@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.
yup, ceammc shows up as "Darwin-amd64-64" for me here, and the binary is "ceammc.d_amd64"
-- 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
On 11/26/2021 1:36 PM, Alexandre Torres Porres wrote:
and the binary is "ceammc.d_amd64"
To avoid confusion this is default extension for Pd on 64bit Arch. Not a "double precision" one.
see http://msp.ucsd.edu/Pd_documentation/x4.htm#s1.2.1
Mensaje telepatico asistido por maquinas.
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.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
Em sex., 26 de nov. de 2021 às 13:41, Christof Ressi info@christofressi.com escreveu:
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.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.
and what other part is of concern now (if any)? :)
--
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Am 26. November 2021 17:39:09 MEZ schrieb Christof Ressi info@christofressi.com:
@christof Deken is prepared for that. "vstplugin~v0.5.3.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.
Thanks lucarda for answering before me: yes, deken is not the problem. At least the Pd side is not a problem at all. There might be issues with the deken cmdline tool detecting the t_float size (the code is there, its just not much tested...)
From my perspective the main problem is co-instability of externals of multiple float sizes: currently if Pd loads an external with the wrong float size, it will stop searching for another external (that might load the right floatsize)
also I would actually like Pd to automatically bridge externals of the wrong floatsize (doing an in place conversion to/from the external's floatsize)
mfg.sfg.jfd IOhannes
Em sex., 26 de nov. de 2021 às 13:54, IOhannes m zmölnig zmoelnig@iem.at escreveu:
From my perspective the main problem is co-instability of externals of multiple float sizes: currently if Pd loads an external with the wrong float size, it will stop searching for another external (that might load the right floatsize)
sounds like an edge case (two externals with the same name, compiled for different systems, without care by the user to make sure to load the right one). Users that want to adventure themselves into this new land and use externals should be able to manage this with [declare] and namespaces. And it also reminds me again of the time we had pd compiled for 64 bits and issues with externals that weren't ready. That didn't stop it from being distributed ;)
On 26.11.2021 17:52, IOhannes m zmölnig wrote:
Am 26. November 2021 17:39:09 MEZ schrieb Christof Ressi info@christofressi.com:
@christof Deken is prepared for that. "vstplugin~v0.5.3.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.
Thanks lucarda for answering before me: yes, deken is not the problem. At least the Pd side is not a problem at all. There might be issues with the deken cmdline tool detecting the t_float size (the code is there, its just not much tested...)
From my perspective the main problem is co-instability of externals of multiple float sizes: currently if Pd loads an external with the wrong float size, it will stop searching for another external (that might load the right floatsize)
Yes! Also, they can't reside in the same folder. Both issues can be easily solved with https://github.com/pure-data/pure-data/issues/902. Of course, this still needs discussion.
However, these issues can be solved later. I kind of agree with Alex now that there is nothing really standing in the way for releasing official double precision builds. Or do you see any real showstoppers?
also I would actually like Pd to automatically bridge externals of the wrong floatsize (doing an in place conversion to/from the external's floatsize)
I don't think this is realistic. You would have to provide wrappers for every single struct and function in m_pd.h (and probably also in the semi-private headers) that has a 't_float' or 't_floatarg'... It would be a massive undertaking.
mfg.sfg.jfd IOhannes