Re: [PD] what's the deal with [utime] object?

2016-02-28 Thread Jonathan Wilkes via Pd-list
> actually i think that a lot of code to review could be identified with a grep for "\bfloat\b", so the chores might not be so horrific. I doubt that would find everything, but that's certainly a good starting point if you're interested in pursuing this. -Jonathan On Sunday, February 28,

Re: [PD] what's the deal with [utime] object?

2016-02-28 Thread IOhannes m zmölnig
On 02/27/2016 06:09 PM, Jonathan Wilkes via Pd-list wrote: >> hmm, what again was wrong with my proposal to distinguish between single > and double precision externals, allowing to have externals that would > work on both precisions ("phat")? [...] > And that's just a single issue with type

Re: [PD] what's the deal with [utime] object?

2016-02-27 Thread Jack
Le 27/02/2016 17:31, IOhannes m zmölnig a écrit : > On 02/27/2016 04:49 PM, Jonathan Wilkes via Pd-list wrote: >>> we should have switched to doubles long ago. >> According to katja, that would trigger a zombie apocalypse in external land. >> > > first of all, we should have switched to

Re: [PD] what's the deal with [utime] object?

2016-02-27 Thread Jack
Le 27/02/2016 16:49, Jonathan Wilkes via Pd-list a écrit : >> we should have switched to doubles long ago. > > According to katja, that would trigger a zombie apocalypse in external > land. > And the only way to tell the zombies from the survivors would be to... > *gulp*... > > actually read

Re: [PD] what's the deal with [utime] object?

2016-02-27 Thread Jonathan Wilkes via Pd-list
> hmm, what again was wrong with my proposal to distinguish between single and double precision externals, allowing to have externals that would work on both precisions ("phat")? The problem I'm describing is how to distinguish between the externals with t_float=double that work as they should,

Re: [PD] what's the deal with [utime] object?

2016-02-27 Thread IOhannes m zmölnig
On 02/27/2016 04:49 PM, Jonathan Wilkes via Pd-list wrote: >> we should have switched to doubles long ago. > According to katja, that would trigger a zombie apocalypse in external land. first of all, we should have switched to doubles *long* ago. > And the only way to tell the zombies from the

Re: [PD] what's the deal with [utime] object?

2016-02-27 Thread Jonathan Wilkes via Pd-list
> It would change some pretty major things in vanilla, too. For instance, > [phasor~], [osc~], and [tabosc4~] all depend on a bit-manipulation trick to > wrap phase, which won't work with doubles. katja addressed this with Pd Double. 

Re: [PD] what's the deal with [utime] object?

2016-02-27 Thread Matt Barber
It would change some pretty major things in vanilla, too. For instance, [phasor~], [osc~], and [tabosc4~] all depend on a bit-manipulation trick to wrap phase, which won't work with doubles. I'm not sure if the output is any different, but it does save the per-sample bounds check and is

Re: [PD] what's the deal with [utime] object?

2016-02-27 Thread Jonathan Wilkes via Pd-list
> we should have switched to doubles long ago. According to katja, that would trigger a zombie apocalypse in external land.  And the only way to tell the zombies from the survivors would be to... *gulp*... actually read external library code. Personally, I'd rather get eaten by a zombie than do

Re: [PD] what's the deal with [utime] object?

2016-02-27 Thread IOhannes m zmölnig
On 02/27/2016 09:40 AM, s p wrote: > Yes, I guessed the issue was with precision, but in that case why would > anyone want to use it? [utime]? i have no idea. what's worse: i have no clue why anyone would *write* that object with the given limitations of a single precision Pd. gmasrd IOhannes

Re: [PD] what's the deal with [utime] object?

2016-02-27 Thread IOhannes m zmölnig
On 02/27/2016 09:55 AM, William Huston wrote: > I really wish Pd had a 32 bit integer data type for counters, and other > places where integers are appropriate. actually i strongly disagree: i think it is one of Pd's killer features to have a single numeric type. the only problem is that the

Re: [PD] what's the deal with [utime] object?

2016-02-27 Thread William Huston
I really wish Pd had a 32 bit integer data type for counters, and other places where integers are appropriate. This problem with single precision floats is my #1 gripe/ buzz-killer (but overall, I am very, very happy with Pd!) e.g. I spent aa few hours with it, but was unable to master the

Re: [PD] what's the deal with [utime] object?

2016-02-27 Thread s p
Yes, I guessed the issue was with precision, but in that case why would anyone want to use it? I was about to use [zexy/time], but [utime] would have been so much simpler in my case ... On Sat, Feb 27, 2016 at 10:23 AM, IOhannes m zmölnig wrote: > On 02/27/2016 12:34 AM, s p

Re: [PD] what's the deal with [utime] object?

2016-02-27 Thread IOhannes m zmölnig
On 02/27/2016 12:34 AM, s p wrote: > Hi! > > I am trying to use [utime] to get an absolute date in seconds since epoch. > However, the number of seconds seems to be rounded, so I don't understand > how is it of any use!? For example, the following patch prints 0 ... > short answer: single

[PD] what's the deal with [utime] object?

2016-02-26 Thread s p
Hi! I am trying to use [utime] to get an absolute date in seconds since epoch. However, the number of seconds seems to be rounded, so I don't understand how is it of any use!? For example, the following patch prints 0 ... [image: Inline image 1] -- *Sébastien Piquemal* -* @sebpiq*