@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~]

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

There are several ways you can turn that into audio.

It would help if you could share a screenshot or pd patch of what you have so far because it can be overwhelming to hear a bunch of things just off the top of my head.

Off the top of my head tho
-using [until< to loop through the math you have or if its made at audio rate use two [snapshot~] to sample the x and y - converting the up/down coordinates to -1 to 1 and dynamically put it into an array/table - the table has to be a power of two + 3 samples 131, 259. This is a periodic waveform that you can then play with tabosc4~ (possibly also putting that into sin~) I made something similar but just getting the point it touches the oval

@Matt-Stalcup said:

In Pd's help files, it suggests table switching with [tabosc4~] to avoid rewriting tables.

I think the help file is simply wrong about this.

AFAIK click-free wavetable switching will require a crossfade, full stop. That is, your workaround isn't a workaround -- it's just the right way to do it.

I can easily reproduce clicks using the help patch's example -- so the help patch itself doesn't even "work" in this sense.

Is there a way to make the table switch happen when the index of the table is at 0 where both tables have the same value (i.e. 0?)

Basically, no. Control messages such as "set" are evaluated only at control block boundaries (default 64 samples). To guarantee that you're switching at the beginning of the wavetable cycle, you would have to be sure that you are at the beginning of the cycle for every control block. That would require a wavelength that is an integer multiple of the block size, which is extremely unlikely condition to satisfy.

hjh

In Pd's help files, it suggests table switching with [tabosc4~] to avoid rewriting tables. However, when I do this, I get small pops in my audio upon switching. I assume these are from the tables switching when the values are far apart, causing the signal to suddenly jump.

Is there a way to make the table switch happen when the index of the table is at 0 where both tables have the same value (i.e. 0?)

thanks for this question and answer! i was just wondering about this since deciding to try out tabosc4~ .

I had been manually setting messages for array sequencer pattern recall...
but uhh.. that wasnt gonna work for waveforms!

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.

Several times I've been wondering why multiple [osc~] or [cos~] are drifting apart.
Now, just found it's a bug, that is known since 2015 (!) but didn't see it come up here on the forum yet:

Pd's cosine table has some small DC-offset.

Here is the pull request:
https://github.com/pure-data/pure-data/pull/106

And there the two relevant patches of this topic from the Pd-mailing-list:

demonstration of drift in FM:
test.pd

https://lists.puredata.info/pipermail/pd-list/2015-11/112204.html

workaround with symmetric and bigger cosine array and [tabosc4~]:
fm-fix.pd

https://lists.puredata.info/pipermail/pd-list/2015-11/112244.html

EDIT
And in here is another patch comparing different tables:
https://github.com/pure-data/pure-data/issues/105
This patch should be proper, as the array uses +3 samples for interpolation.

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

... and now I can not hear a difference between cos-GOOD and [osc~] !
So this bug seems to be solved !!?

@jameslo Thank you soooooo much jameslo!Your patch inspire me a lot!Although it takes me about 2 hours to understand it
I made another version base on your |tableIndexer| idea. And I add |file sample rate/system sample rate| to prevent pitch shift.Well......two things I still don't understand:

• I used |expr $v1<start| in my patch directly but I got message ：receive~ end: vector size mismatch,receive~ start: vector size mismatch.After I deleted |block~ 1 1 1| there was no such message,I'm not sure if they're relevant.

• I notice you use |nrSamples - 2| to valid indexes for 4 point interpolation.But when we apply sinesum function like:|;array1 sinesum 128 1 1|,then there will be 131 samples in array1. So should we add point into it like tabosc4~ help.pd says:'one at the beginning and two at the end, which should be wraparound copies of the last point and the first two points, respectively', but Im confused by tabread4~ help.pd....it did say 'Indices should range from 1 to (size-2)'
  rpole looping scrubber JZ.pd
  rpole looping scrubber JZ.mp4

Looking forward to the reply,have a nice day!

@Matt-Stalcup

wavebypartialx10.zip

Sorry, it's taken me so long to get back with you.

1. re: $1,$0- that is there so you can route "from afar" from those tables (you'll see this in the x10 file I included in the zip. Harder to do if the array is $0.
2. the line makes sense. Thanks.
3. tabosc4~ good idea. The x10 uses an abstraction I built around the same time I did this, gensyn~ (generic synthesizer) which includes those as its double-osc (see https://forum.pdpatchrepo.info/topic/13099/gensyn-generic-multi-modulator-synthesizer-abstraction for more info).
4. the xysl has an object in it at the very top: [iemguts/receivecanvas] where the creation argument defines what level-up of parent you want the mouse to be active, i.e. which level of grandparent. The original xysl abs hardcodes it at 1, meaning only the parent patch will be allow it to move. I have included my modified version which only includes changed integers out and the depth as $6 creation argument. Seems to help with the performance issue. As the x10/gensyn~ runs at about 5-10% on my old-ish desktop.

I am thrilled you like the patch. Always good to know the work is helping out.

I made the x10 version for you to consider. The notion of routing different tables to different clones, doesn't make a lot sense, but it does show this will work even with a high number of (cloned) tabosc~s.

Thanks, again for you input and help in making it better.

Peace through Music.
Love thru Sharing.
-s