Hey! Valuska-Yoshimitsu is my other account I made because I had temporarily lost access to the email for this one.

I've been playing with this and it sounds beautiful. Thanks for your work.

I made a couple of changes:

-changed the $1 arguments naming the wavetable to $0
-added [line] objects after the xysl router to smooth out transitions]
-added [tabosc4~] and accompanying outlet/inlet
-added an inlet for a xysl as it comes packaged. (i'm not sure why, but i can't get xysl to respond when it's in a subpatch or abstraction. Additionally, not sure how you got it to data scale the way you did, so I added glue in wavebypartial for data scaling)

Here's the updated version-wavebypartial_b_2(viaxyslider).zip

Finally, I absolutely love the way this sounds: I want to run like 10 of them at once. Unfortunately, it's cpu expensive. My guess is that it's all of the sinesums going on.

I've thought for a while now that it could be possible to achieve this waveshaping effect by creating a huge bank of tables instead of running sinesum every time you want to switch. This is probably foolish, but I'm curious if you have any thoughts.

Thanks again!

I don't know if that helps, but here is a patch that uses ifft instead of sinesum message to compute a table for tabosc4~.
In my experience, it produces no (or less) glitches
sinesum.pd

Hello,

Just joined the forums here. I'm still fairly new to PD so this may be the first of a long series of questions to help me achieve a college project.

So for this 1st one, I have a wavetable oscillator reading from a message using a "sinesum" synthesis implementation. The $1 put here is just a placeholder to indicate I will have a list of partials (up to a hundred) with different amplitudes. But the important part is that this list will be constantly updated in real-time, at audio rate.

How can I go about creating a dynamically changing list (which will have to be derived from an array as I will be performing real-time maths on all elements of this array) and constantly update the message box here so that the [tabosc4~] is also updated in real-time.

Note: this is a yet incomplete post, I will add more info in the hours to come, but feel free to post suggestions if you have any at this stage.

@yannseznec
Yes 2048 will work but 2045 will reduce to the next lower size that is possible........ 1026 (1024+2 for optimal use with interpolation).
I think sinesum is made to work that way because some objects like [tabosc4~] require a power of 2 + 3 points for wraparound to work efficiently with interpolation.
It could do what you ask but then when you use your array you would run into problems.... so it doesn't.
David.

While working with square and pulse waves, I found that certain frequencies produce a sort of overlapping effect, which I believe happens when the frequency and the precision level of a float don't mix well together. In any case, it can be remedied by adding a slope between value changes.

Much like tabread4~ and tabosc4~, these objects work best with tables whose size is a power of 2, plus three. Linear interpolation really only requires 1 additional point, such that the first and last points are the same value, but for the sake of compatibility, the wave starts at index 1, while index 0 is just ignored. Pd's 4-point interpolation has 1 look-behind point and expects the beginning of the wave to be at index 1. Messages like sinesum and cosinesum generate arrays with this in mind.

The 2nd inlet is a signal inlet and it adjusts the interpolation threshold, which can be thought of as the percentage of each point that should remain as the original value. So if the threshold is 0.9, that means that only the last 10% of the point will be dedicated to interpolation.

The zip comes with help files and Linux/Windows/Mac builds of the externals.
tab2.zip

I think is something with catch and throw limitations.operadores.pd
I'm in the work, i could not connect it right here, or create default values but the main issues are once you have the two routes connected proprerly, it will sound in just one of them.
Perhaps i have to use tabosc4 or sinesum, do you have any basic examples to use with fm, i found https://forum.pdpatchrepo.info/topic/10745/3-op-fm-synth-with-mod-matrix/3 but is over my head

the patch I posted specifically? You can make your own delay line with arrays but if you're using vanilla the actual buffer (array) size has to be a multiple of 64 because that's the rate that [tabwrite~] gets bangs
and the amount of delay time you can actually use is the array size - audio block size because if it's greater then the writer and the reader will overlap each other.

@Load074 Hi, my guess is that using a phasor~ in parallel and displaying the output of that instead should be accurate, although I have no way of checking that.

tabosc4.pd

Is there a quick way to see where tabosc4~ is in its cycle? I want to have a display with a [hsl] moving as tabosc~ goes slowly (and at varying speeds) across a waveform.
I don't want to simply do some predictive math, because the oscillation speed is changing too much. I'm sure they'd get out of sync.
I realize that if I'd been using tabread4~ I'd have been supplying that info... but I'm not going back to change my patch now.
I think the answer is "no." There's only one output, so I don't see how I could get it.
Thanks gang!

I've been roughly measuring the performance of pd's audio atoms by creating large arrays of them in a subpatch and monitoring overall CPU usage. I'll post the measurement patch if there's demand.

bob~ 168.00
vline~ 80.00
bonk~ 50.00
sigmund~ 43.00
line~ 21.50
pow~ 19.25
mtof~ 14.50
exp~ 10.50
vcf~ 8.25
log~ 7.00
framp~ 7.00
sqrt~ 5.50
q8_sqrt~ 5.50
rsqrt~ 5.25
q8_rsqrt~ 5.25
rfft~ 5.00
tabread4~ 5.00
osc~ 3.50
cos~ 3.50
bp~ 3.50
tabread~ 2.50
rpole~ 2.25
lop~ 2.22
phasor~ 2.00
tabosc4~ 2.00
/~ 1.67
ftom~ 1.63
rzero~ 1.25
abs~ 1.06
clip~ 1.00
threshold~ 1.00
vsnapshot~ 1.00
tabwrite~ 0.88
hip~ 0.72
+~ 0.61
*~ 0.61
-~ 0.61
snapshot~ 0.50