Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Lucas Cordiviola
I have also requested this: https://lists.puredata.info/pipermail/pd-dev/2019-12/022203.html :) Mensaje telepatico asistido por maquinas. On 2/26/2020 9:58 AM, Christof Ressi wrote: I see you point and I think it's a philosophical issue. In Supercollider, for example, I can't compile a UGen

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Lucas Cordiviola
I have requested this as it will be more simple for me to upload double-precision externals builds from my current w64 deken (I have uploded (many, almost all) the with sources and pd-lib-builder so it shouldn't be hard to have windows32/windows64 double builds) :) Mensaje telepatico

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Alexandre Torres Porres
Em qua., 26 de fev. de 2020 às 10:30, IOhannes m zmoelnig escreveu: > i think alex really meant: "I've tested loading externals and it just > doesn't create[,] and [instead] complain[s]." > yup ___ Pd-dev mailing list Pd-dev@lists.iem.at

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread IOhannes m zmoelnig
On 26.02.20 14:26, Christof Ressi wrote: >> I've tested loading externals and it just doesn't create and complain > > Are you sure? Turn on log level 4. i think alex really meant: "I've tested loading externals and it just doesn't create[,] and [instead] complain[s]." mgfsdr IOhannes

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread IOhannes m zmoelnig
On 26.02.20 14:22, IOhannes m zmoelnig wrote: > On 26.02.20 14:12, Alexandre Torres Porres wrote: >> I've tested loading externals and it just doesn't create and complain, but >> trying to load cyclone with [declare -lib cyclone] crashes Pd! > > could that be a duplicate of >

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Christof Ressi
I've tested loading externals and it just doesn't create and complain Are you sure? Turn on log level 4. Here's what I get when I try to load a single precision [markex/randomF] in my double precision built: refusing to load 32bit-float object 'randomF' into 64bit-float Pd maximum object

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread IOhannes m zmoelnig
On 26.02.20 14:12, Alexandre Torres Porres wrote: > I've tested loading externals and it just doesn't create and complain, but > trying to load cyclone with [declare -lib cyclone] crashes Pd! could that be a duplicate of ? fgmasdf

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread IOhannes m zmoelnig
On 26.02.20 14:09, Dan Wilcox wrote: > Forgive me if this has been gone over, but what's the behavior if a > single-precision Pd tries to load a double-precision external or vice versa? > Does it fail to load or simply crash? with Pd>=0.51, the class_new will refuse to register the objectlcass

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Alexandre Torres Porres
Em qua., 26 de fev. de 2020 às 10:09, Dan Wilcox escreveu: > Forgive me if this has been gone over, but what's the behavior if a > single-precision Pd tries to load a double-precision external or vice > versa? Does it fail to load or simply crash? > > If it crashes, maybe there needs to be some

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Dan Wilcox
Forgive me if this has been gone over, but what's the behavior if a single-precision Pd tries to load a double-precision external or vice versa? Does it fail to load or simply crash? If it crashes, maybe there needs to be some mechanism to query the compiled precision of the external, ie. some

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Christof Ressi
I see you point and I think it's a philosophical issue. In Supercollider, for example, I can't compile a UGen plugin and expect it to run on both Scsynth and Supernova, I rather have to pass the correct define ("SUPERNOVA"). Plugins are therefore usually built twice - with and without

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Alexandre Torres Porres
Em qua., 26 de fev. de 2020 às 09:50, Christof Ressi escreveu: > The other possibility would be that the GUI objects perform some kind of > rounding in double precision mode according to the box width. > Yeah, I think that definitely would be the best feature/solution

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Christof Ressi
Yes, but additional digits are just truncated, there's no rounding. The problem IOhannes mentioned is that with double precision you more often encounter situations where you don't get exact numbers because the rounding happens much later. So you might something like 3.9 in double

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Alexandre Torres Porres
Em qua., 26 de fev. de 2020 às 09:29, Christof Ressi escreveu: > I can see that showing too many digits can be annoying in number boxes > But you can set the width/digits of number boxes, it's not that now all boxes will change and show more numbers, and by default it still is 5 digits.

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Christof Ressi
I can see that showing too many digits can be annoying in number boxes, but in object boxes, where the number is (usually) typed by the user, the higher precision is certainly desirable. At the very least, Pd should *save* the number with a higher precision. Christof On 26.02.2020 12:48,

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Christof Ressi
PS: i'm absolutely sure i write this up before (months, years ago?) but cannot find it anymore :-( I think I found it :-) https://github.com/pure-data/pure-data/pull/807#issuecomment-561251729 On 26.02.2020 10:09, IOhannes m zmoelnig wrote: (i'm not sure how this ended on pd-list, m oving it

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Alexandre Torres Porres
Em qua., 26 de fev. de 2020 às 08:31, IOhannes m zmoelnig escreveu: > no. see https://github.com/pure-data/pure-data/pull/807#issue-348421658 hmm, I see a discussion about pd being able to have double precision numbers but the GUI not being able to hold it. I don't understand why. I'd like to

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Alexandre Torres Porres
Em ter., 25 de fev. de 2020 às 20:44, Alexandre Torres Porres < por...@gmail.com> escreveu: > I was expecting to see huge numbers in the atom boxes and print, but I > still get it with the same resolution as before. > So, does it mean we still have single precision on floats?

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Alexandre Torres Porres
well, let me ask this again. Will we have for download both the single and double-precision Pds? Makes sense to me it'd be officially either single or double - hence double it'd be, so we could enjoy more precision. So, what's the plan? And what would we need to adapt and compile externals

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread IOhannes m zmoelnig
(i'm not sure how this ended on pd-list, m oving it back to pd-dev) On 25.02.20 23:53, Dan Wilcox wrote: >> On Feb 25, 2020, at 11:41 PM, Christof Ressie wrote: >> >> I think there's no configure flag (yet). In the meantime you can >> compile Pd with >> >> make CPPFLAGS="-DPD_FLOATSIZE=64" > >