Le 2012-02-15 à 12:07:00, Miller Puckette a écrit :
That's an open question; I'm not sure whether computing the length of a blockin msec and then sending it to "delay", for instance, would always round back to the exact number of Pd ticks in a block.
It depends on how you do it. See attached patch to see that [int] helps find a lot of cases of (1/x)*x = 0.999999... But there are less than how I think there would be.
If replacing truncation by actual rounding, then the problem disappears.
C's (int) and C++'s int() are the same as Pd's [int].
(A pd tick, internally, is small enough that one millisecond and one sample both are integer numbers of ticks, at least provided the SR is one of the "standard" ones.)
That's actually the ppcm of 192 and 88,2 kHz.
There would still be the problem of round-off errors for larger delays - the only way I can see to manage that is to have the time objects have a notion of unit.
Would a similar things happen to all objects that take frequencies ?
[osc~ 4 kHz] means 4000
[osc~ 1382.3 rad/s] means 220
[osc~ 36000 deg/s] means 100
[osc~ 2 ms] means 500
[osc~ 69 midi] means 440
[osc~ 180 bpm] means 3
and don't forget barks...
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC