> 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,
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
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
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
> 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,
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
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
> 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
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
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
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
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
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
13 matches
Mail list logo