Re: [PD] documenting messages to/from Pd and dynamic patching
+1 to having them in the docs but clearly labelled as something along the lines of "not in the public API - may change without notice". That kind of stuff is really helpful to people coming up on the whole system to better understand how it all works. my two cents Canadian. :-) On Fri, Nov 26, 2021 at 4:15 PM Alexandre Torres Porres wrote: > Em sex., 26 de nov. de 2021 às 20:19, João Pais > escreveu: > >> I don't see a mention to these messages: mouse, mouseup, mousedown, >> relocate. And also all other messages related to gui stuff. >> > > yeah, I didn't put it. It felt like something hard to document and for > more extreme cases. And now that Christof says I should really keep out of > this dark corner, I wonder if I did right. > > >> It could also be clearly mentioned that subpatches receive messages sent >> to pd-[subpatch], and abstractions are named [abstraction].pd (if I'm >> recalling correctly) - unless there is a namecanvas used in those. >> > > how isn't it clearly mentioned? > ___ > 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
Re: [PD] documenting messages to/from Pd and dynamic patching
Em sex., 26 de nov. de 2021 às 20:19, João Pais escreveu: > I don't see a mention to these messages: mouse, mouseup, mousedown, > relocate. And also all other messages related to gui stuff. > yeah, I didn't put it. It felt like something hard to document and for more extreme cases. And now that Christof says I should really keep out of this dark corner, I wonder if I did right. > It could also be clearly mentioned that subpatches receive messages sent > to pd-[subpatch], and abstractions are named [abstraction].pd (if I'm > recalling correctly) - unless there is a namecanvas used in those. > how isn't it clearly mentioned? ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
I don't see a mention to these messages: mouse, mouseup, mousedown, relocate. And also all other messages related to gui stuff. It could also be clearly mentioned that subpatches receive messages sent to pd-[subpatch], and abstractions are named [abstraction].pd (if I'm recalling correctly) - unless there is a namecanvas used in those. People, I'm on a roll here, updating much of the help files and documentation. I just hit an important new addition, documenting "Messages to/from Pd" and "Dynamic Patching" I'd like you people to revise it. Here's the commit => https://github.com/pure-data/pure-data/pull/1455/commits/0ec5429629eb1045c901ab9c74befd124ccb6e69 already in an open PR Cheers ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
Em sex., 26 de nov. de 2021 às 17:18, Christof Ressi escreveu: > don't advertize "coords" (at least you didn't mention "donecanvasdialog") > because that one should really be replaced by > https://github.com/pure-data/pure-data/pull/627 (hopefully in the next Pd > release :-) > yeah, makes sense to wait for this. Now, is the next '0.52-0 final'? :) i know it's not :( ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
> In particular, please don't include any GUI dialog messages which are they all? anyway, I felt I was crossing a line, hence I'm waving here to the judges :) For instance, [namecanvas] did include a 'msg' message to canvas. I count that as a modest dynamic patch documentation. Also, many of us use and abuse these for ages now... what if the documentation also gives us a "heads up", some "warning" that this is unstable and should be used assuming risks? This would be better than just having people check for this kind of documentation in Pd-extended or something and worse stuff. But I see this might needs lots of debates, and as soon as I have more input I can revise and move this to a github discussion and a parallel PR. thanks Em sex., 26 de nov. de 2021 às 17:18, Christof Ressi escreveu: > I think there are definitely many "official" messages (e.g. "dsp", > "fast-forward", "quit", etc.) that need to be documented properly, so in > principle I very much welcome this effort. > > However, I'm rather sceptical about including any "dynamic patching" > messages in the official documentation as they are not officially > supported. I think it would be better to exclude this from the main PR ( > https://github.com/pure-data/pure-data/pull/1455) and only offer this as > a secondary PR (that you can rebase regularly on top of the other one). > > In particular, please don't include any GUI dialog messages. Those are > really internal. Also, don't advertize "coords" (at least you didn't > mention "donecanvasdialog") because that one should really be replaced by > https://github.com/pure-data/pure-data/pull/627 (hopefully in the next Pd > release :-) > > I think including dynamic patching would "taint" your otherwise great > documentation updates. > > Christof > On 26.11.2021 21:05, Alexandre Torres Porres wrote: > > the reason I ask for revisions here is that I'm not an expert on this dark > magic, so I'm not 100% sure about things. I can revert the commit in the PR > and keep it on the fridge for the next release update if the real wizards > see problems on it. > > Em sex., 26 de nov. de 2021 às 16:59, Alexandre Torres Porres < > por...@gmail.com> escreveu: > >> I could just send the main Patch, but it just works best if you have all >> of the current state of the reference folder and also check other changes >> I'm proposing in this PR, so see attachment of the whole thing. >> >> I got a rather broken keyboard, so I must be generating more typos than >> usual. Will need to revise it! >> >> note that [Pd-messages] gets called in the help files of [send-receive], >> 'message boxes' and [namecanvas], all of them have been rewritten as well. >> >> cheers >> >> >> >> Em sex., 26 de nov. de 2021 às 16:55, Alexandre Torres Porres < >> por...@gmail.com> escreveu: >> >>> People, I'm on a roll here, updating much of the help files and >>> documentation. >>> >>> I just hit an important new addition, documenting "Messages to/from Pd" >>> and "Dynamic Patching" >>> >>> I'd like you people to revise it. >>> >>> Here's the commit => >>> https://github.com/pure-data/pure-data/pull/1455/commits/0ec5429629eb1045c901ab9c74befd124ccb6e69 >>> >>> already in an open PR >>> >>> Cheers >>> >> > ___pd-l...@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
Re: [PD] documenting messages to/from Pd and dynamic patching
I think there are definitely many "official" messages (e.g. "dsp", "fast-forward", "quit", etc.) that need to be documented properly, so in principle I very much welcome this effort. However, I'm rather sceptical about including any "dynamic patching" messages in the official documentation as they are not officially supported. I think it would be better to exclude this from the main PR (https://github.com/pure-data/pure-data/pull/1455) and only offer this as a secondary PR (that you can rebase regularly on top of the other one). In particular, please don't include any GUI dialog messages. Those are really internal. Also, don't advertize "coords" (at least you didn't mention "donecanvasdialog") because that one should really be replaced by https://github.com/pure-data/pure-data/pull/627 (hopefully in the next Pd release :-) I think including dynamic patching would "taint" your otherwise great documentation updates. Christof On 26.11.2021 21:05, Alexandre Torres Porres wrote: the reason I ask for revisions here is that I'm not an expert on this dark magic, so I'm not 100% sure about things. I can revert the commit in the PR and keep it on the fridge for the next release update if the real wizards see problems on it. Em sex., 26 de nov. de 2021 às 16:59, Alexandre Torres Porres escreveu: I could just send the main Patch, but it just works best if you have all of the current state of the reference folder and also check other changes I'm proposing in this PR, so see attachment of the whole thing. I got a rather broken keyboard, so I must be generating more typos than usual. Will need to revise it! note that [Pd-messages] gets called in the help files of [send-receive], 'message boxes' and [namecanvas], all of them have been rewritten as well. cheers Em sex., 26 de nov. de 2021 às 16:55, Alexandre Torres Porres escreveu: People, I'm on a roll here, updating much of the help files and documentation. I just hit an important new addition, documenting "Messages to/from Pd" and "Dynamic Patching" I'd like you people to revise it. Here's the commit => https://github.com/pure-data/pure-data/pull/1455/commits/0ec5429629eb1045c901ab9c74befd124ccb6e69 already in an open PR Cheers ___ 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
Re: [PD] documenting messages to/from Pd and dynamic patching
new commit, forgot about 'dirty' https://github.com/pure-data/pure-data/pull/1455/commits/8fe7ff12419c797bf33e6ff0409798d089dfba25 patch attached Em sex., 26 de nov. de 2021 às 17:05, Alexandre Torres Porres < por...@gmail.com> escreveu: > the reason I ask for revisions here is that I'm not an expert on this dark > magic, so I'm not 100% sure about things. I can revert the commit in the PR > and keep it on the fridge for the next release update if the real wizards > see problems on it. > > Em sex., 26 de nov. de 2021 às 16:59, Alexandre Torres Porres < > por...@gmail.com> escreveu: > >> I could just send the main Patch, but it just works best if you have all >> of the current state of the reference folder and also check other changes >> I'm proposing in this PR, so see attachment of the whole thing. >> >> I got a rather broken keyboard, so I must be generating more typos than >> usual. Will need to revise it! >> >> note that [Pd-messages] gets called in the help files of [send-receive], >> 'message boxes' and [namecanvas], all of them have been rewritten as well. >> >> cheers >> >> >> >> Em sex., 26 de nov. de 2021 às 16:55, Alexandre Torres Porres < >> por...@gmail.com> escreveu: >> >>> People, I'm on a roll here, updating much of the help files and >>> documentation. >>> >>> I just hit an important new addition, documenting "Messages to/from Pd" >>> and "Dynamic Patching" >>> >>> I'd like you people to revise it. >>> >>> Here's the commit => >>> https://github.com/pure-data/pure-data/pull/1455/commits/0ec5429629eb1045c901ab9c74befd124ccb6e69 >>> >>> already in an open PR >>> >>> Cheers >>> >> Pd-messages.pd Description: Binary data ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
the reason I ask for revisions here is that I'm not an expert on this dark magic, so I'm not 100% sure about things. I can revert the commit in the PR and keep it on the fridge for the next release update if the real wizards see problems on it. Em sex., 26 de nov. de 2021 às 16:59, Alexandre Torres Porres < por...@gmail.com> escreveu: > I could just send the main Patch, but it just works best if you have all > of the current state of the reference folder and also check other changes > I'm proposing in this PR, so see attachment of the whole thing. > > I got a rather broken keyboard, so I must be generating more typos than > usual. Will need to revise it! > > note that [Pd-messages] gets called in the help files of [send-receive], > 'message boxes' and [namecanvas], all of them have been rewritten as well. > > cheers > > > > Em sex., 26 de nov. de 2021 às 16:55, Alexandre Torres Porres < > por...@gmail.com> escreveu: > >> People, I'm on a roll here, updating much of the help files and >> documentation. >> >> I just hit an important new addition, documenting "Messages to/from Pd" >> and "Dynamic Patching" >> >> I'd like you people to revise it. >> >> Here's the commit => >> https://github.com/pure-data/pure-data/pull/1455/commits/0ec5429629eb1045c901ab9c74befd124ccb6e69 >> >> already in an open PR >> >> Cheers >> > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] documenting messages to/from Pd and dynamic patching
People, I'm on a roll here, updating much of the help files and documentation. I just hit an important new addition, documenting "Messages to/from Pd" and "Dynamic Patching" I'd like you people to revise it. Here's the commit => https://github.com/pure-data/pure-data/pull/1455/commits/0ec5429629eb1045c901ab9c74befd124ccb6e69 already in an open PR Cheers ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] pd double precision
On 26.11.2021 17:52, IOhannes m zmölnig wrote: Am 26. November 2021 17:39:09 MEZ schrieb Christof Ressi : @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. 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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] pd double precision
Em sex., 26 de nov. de 2021 às 13:54, IOhannes m zmölnig 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 ;) ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] pd double precision
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. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] pd double precision
Am 26. November 2021 17:39:09 MEZ schrieb Christof Ressi : > >> >> @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. > 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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] pd double precision
If precision does not match Pd refuse to load (IIRC). correction: Pd refuses to load the external. -- Mensaje telepatico asistido por maquinas. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] pd double precision
Em sex., 26 de nov. de 2021 às 13:41, Christof Ressi 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](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. > 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 < > i...@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-l...@lists.iem.at mailing > list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > > > ___pd-l...@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
Re: [PD] pd double precision
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 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 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
Re: [PD] pd double precision
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 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
Re: [PD] pd double precision
Em sex., 26 de nov. de 2021 às 13:33, Lucas Cordiviola < lucard...@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 < > i...@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-l...@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
Re: [PD] pd double precision
@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. -- 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 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
Re: [PD] pd double precision
Em sex., 26 de nov. de 2021 às 13:19, Christof Ressi 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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] pd double precision
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 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
Re: [PD] pd double precision
Em sex., 26 de nov. de 2021 às 10:50, Christof Ressi 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
Re: [PD] pd double precision
@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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] pd double precision
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
Re: [PD] pd double precision
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 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 > 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-l...@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
Re: [PD] pd double precision
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 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
Re: [PD] pd double precision
Em sex., 26 de nov. de 2021 às 05:56, hans w. koch 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
Re: [PD] pd double precision
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 : > > 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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
