When feeding a line~ with message 0, 1000 1000 into a cosine
So , play 1000 during 1000 ms there is severe aliasing but only after 500 ms of playing ( see sidebands )

@gentleclockdivider Sounds unaliased to me

imo this is a weird usage of [cos~]. why not just feed a single frequency into [osc~]? anywaways if you are set on doing it this way you could try using [vline~] and see if it's any better because [vline~] uses doubles. you could also try using [wrap~] before [cos~].

but you might also be getting artifacts in the spectrogram from a sudden change in frequency (to 0)...

edit: basically it's not recommended to use large numbers to drive [cos~] but I forget if [wrap~] helps or not. the error might be present at that point already..
edit2: personally I use my own sine tables if I want really clean sine waves because the ones pd uses internally still sound a bit gritty to me sometimes, I think they use 512 points and I usually end up using tables that use 2048 or 4096 points

@seb-harmonik.ar said:

the error might be present at that point already..

yes, it might be a precision-thing.

Comparing Pd's [cos~]ine-table with [tabread4~ $0-cos-GOOD] from this patch:
https://github.com/pure-data/pure-data/issues/105
(see https://forum.pdpatchrepo.info/topic/13709/bug-osc-cos-circle-asymmetry-drifting-out-of-phase )

Driving them with a large number added, same artefacts appear.

Offtopic, but
without any addition [+~ 0] $0-cos-GOOD is slightly cleaner:

Sounds unaliased to me

< -90 dB we can't hear that.

late EDIT:
since Pd 0.55 and ongoing, Pd's cosine table has changed to a higher resolution and might get further changes for symmetry. See release notes and https://lists.puredata.info/pipermail/pd-dev/2024-06/023715.html

@lacuna I think there might be error in the increment with large numbers as well.
as in the internal 32-bit floats in [line~] will increment the internal representation with less accuracy for larger numbers as well, whereas [phasor~] will at least store the correct number internally.

I see, all kinds of precision errors in every stage. Didn't know [vline~] was calculating in double-precision. Thank you!

And didn't see your 2nd edit:

@seb-harmonik.ar said:

edit2: personally I use my own sine tables if I want really clean sine waves because the ones pd uses internally still sound a bit gritty to me sometimes, I think they use 512 points and I usually end up using tables that use 2048 or 4096 points

Here is a rather messy patch comparing different tables and interpolations I started to make a while ago, maybe worth sharing here:

Bigger tables are more robust against precision errors (offset) of their driving inputs.
With offset, [cyclone/cycle~] has same few artefacts for smaller as for bigger arrays (hmm..might be a bug I did?).
[osc~] is the cheapest sine.
[cyclone/cycle~] has non-expected costs with different interpolations.
My linear interpolation is different than cyclone's in results and very expensive (due to vanilla patching!?).
At an offset above [+~ 1023], with [cos~] and 512-point-table called $0-cos-GOOD, there is a sudden increase of artefacts .(due to bit-depth!!?)

puresine.zip

There might be bugs. Sorry for the mess, too boring cleaning up this time.

you dont want to go to 1000 in 1000, you want to go to 1.