An old post, but just spotted:

https://forum.pdpatchrepo.info/topic/8940/manipulate-video-with-sound/10 :

There are limitations to the length of the audio file that can be loaded into ram and played (90sec) in 32-bit Pd, that can be overcome with some difficulty...

SuperCollider also uses 32-bit floats for audio processing, and our documentation notes that BufRd (analogous to [tabread4~]) can go up to about 6 minutes at 44.1 kHz.

Possibly this is because SC provides a Phasor that is designed for buffer reading, where the default increment is 1.0. Pd's [phasor~] calculates the increment as frequency / sampleRate (the nearest analog in SC is LFSaw, not Phasor).

When accumulating 1's, the output value will be exact up to the 24-bit mantissa precision (23 mantissa bits are stored, plus one implicit "1" to the left of the binary point). Binary floating-point values are exact when the denominator of the fraction is a power of two. The denominator of an integer value is 1 == 2 ^ 0, so, no problem up to (2 ** 24) - 1.

Dividing by sample rate to get the increment will introduce inaccuracy, but it is not the only way to produce buffer indices.

I tested at 48 kHz with a 5'30" sine tone, written into a file. If I get the sample positions from [rpole~] accumulating 1.0, it sounds clean, even starting at around the 5 minute mark.

hjh

internally phasor~ uses something like 32-bit fixed-point. So the comparative error is really introduced when multiplying by the buffer size I guess.

Also looking at what I think is the Phasor code, it looks to me like it outputs 64-bit doubles.. https://github.com/supercollider/supercollider/blob/137cb4cd56f5bdf4484c9ad6761d4724dc8d7818/server/plugins/TriggerUGens.cpp#L134

I think the difference is that the output of Phasor is already scaled and output as a 64-bit value before being converted to 32-bit whereas when using phasor~ it is output as 32-bit and also scaled from range 0-1 as a 32-bit by multiplying by buffer size

If there were a Phasor equivalent in pd it might be comparable..
(and that also seems to be the case if [rpole~] gives similar results)
[vline~] should work as well

@seb-harmonik.ar said:

internally phasor~ uses something like 32-bit fixed-point. So the comparative error is really introduced when multiplying by the buffer size I guess.

Must be.

Also looking at what I think is the Phasor code, it looks to me like it outputs 64-bit doubles.

SC UGens are free to use doubles internally, but the interconnection buffers are single precision, so we do run into trouble at that 24 bit mantissa limit.

I think the difference is that the output of Phasor is already scaled and output as a 64-bit value before being converted to 32-bit...

I think it's a bit more than that. When the phase increment is 1 buffer frame per output sample, then there is no inaccuracy at all, because integer values are never repeating fractions, and up to 2^24, are not subject to truncation (2^24 - 1 is ok but 2^24 + 1 is not). It avoids the problem of scaling inaccuracy by not scaling at all -- which may be what you meant, just being clear about it. rpole's similar results are because my example is integrating a stream of 1's, so everything is integer valued.

It struck me interesting how the correct observation "buffer playback by scaling phasor~ runs into trouble quickly" slips into a generalized caution. Agreed that the phasor~ way isn't sufficient for many use cases; perhaps a new object would be useful, or, the accumulator technique would be useful as a more prominent part of pd culture.

hjh

phasor~ way isn't sufficient for many use cases; perhaps a new object would be useful, or, the accumulator technique would be useful as a more prominent part of pd culture.

@ddw_music Just chiming in, to say thank you.
I am always interested in how to make Pd sound better: Not only looking for more Pd-double developement, but also for such basic insights.

Vanilla's oscillators use the "Höldrich method", of which I get an idea, but – like most of us? - do not understand fully in depth.
So don’t want to muddy the waters.

Just sharing some related links on the topic:

[phasor~]'s source:
https://github.com/pure-data/pure-data/blob/master/src/d_osc.c

Miller on the method:
http://lalists.stanford.edu/lad/2000/Sep/0188.html

@seb-harmonik.ar explaining:
https://forum.pdpatchrepo.info/topic/8691/generating-sines-in-plain-c-on-arm-understanding-osc-guts/3

Does Pd have a "sound"? (vs. SC)
https://lists.puredata.info/pipermail/pd-list/2016-02/113248.html
(...discussion containing partly false information, too I think...)

A stub, not explaining the method:
https://github.com/TonicAudio/Tonic/wiki/Fast-Phasor-ala-R.-Hoelderich

(The quoted paper appears to be the wrong one or missing:
1995 ICMC“An Accurate Signal Representation for Sound Resynthesis Utilizing a Time-Frequency Mapping of the DFT-Magnitude”
it is not. )

** also wondering if [tabplay~] simply accumulates?
And how does [loop~] do? And [tabosc4~] ?

@lacuna [tabplay~] can just accumulate an integer internally for the sample index as it doesn't need resampling/fractional indices
looks like [tabosc4~] does the essentially same thing as [osc~]
[loop~] uses doubles internally, but also outputs to a 32-bit float in the range 0-1, so similar issue to [phasor~]