Also, in case it wasn't clear, you should open those in 0.54 or with 0.54 compatibility. The new osc~ in 0.55 does much better.
MB On Thu, Jun 6, 2024 at 2:04 PM Matt Barber <[email protected]> wrote: > Yep, this one, with a one-shot [until] through the indices into $0-cos-BAD > is better than cosinesum in the previous patch, but it still drifts > visibly/audibly after a couple minutes; obviously wouldn't be as much of a > problem in double precision, though. > > > > > > On Thu, Jun 6, 2024 at 1:53 PM Matt Barber <[email protected]> wrote: > >> Here's the demonstration. While the symmetric table will eventually drift >> a little, it stays stable for far longer than osc~ or cosinesum. Although, >> to be fair, the real test in building a cosine table from scratch in Pd >> would be to fill the table using [cos], walking through indices and >> dividing by table size to get phase. >> >> Matt >> >> On Thu, Jun 6, 2024 at 1:39 PM Matt Barber <[email protected]> wrote: >> >>> The main reason for symmetry was stable FM synthesis – when you modulate >>> frequency, any overall differences in the shape of the cosine wave shape >>> accumulate quickly as an error in the osc~'s phase increment, causing >>> significant drift in the spectrum. It's not a problem when you modulate >>> phase directly since the modulator is decoupled from the phasor. >>> >>> MB >>> >>> On Thu, Jun 6, 2024, 1:24 PM Miller Puckette <[email protected]> >>> wrote: >>> >>>> Precisely that: cache pollution in general. At some point the overall >>>> speed of the program will suffer, depending on CPU design, cache size, >>>> and probable other factors. >>>> >>>> If the input to a cos~ object (for example) is between 1 and 2 you'll >>>> get the same loss of accuracy but still there will be rounding behavior >>>> that will (probably) give unsymmetric behavior. >>>> >>>> Anyway, I don't remember hearing any reason why symmetry should be >>>> important in itself. >>>> >>>> cheers >>>> >>>> M >>>> >>>> On 6/6/24 6:51 PM, Matt Barber wrote: >>>> > Since cos~ wraps, one could theoretically take advantage of the equal >>>> > distribution of float values between 1.0 and 2.0. >>>> > >>>> > Profiling a larger table would be useful – I prefer accuracy over >>>> > performance in general, but I wonder where the performance hit would >>>> > come from, outside of unpredictable cache misses. >>>> > >>>> > >>>> > >>>> > On Thu, Jun 6, 2024, 11:25 AM Miller Puckette >>>> > <[email protected]> wrote: >>>> > >>>> > Well, as far as I can tell making the table "symmetric" won't >>>> > matter at >>>> > all since, for instance, 0.1 and 0.9 won't give the same lookup >>>> > values >>>> > anyway because they can't themselves be represented exactly and >>>> > will be >>>> > truncated differently (0.1 will be more accurately represented >>>> than >>>> > 0.9). On the other hand, values like 0.25 or -0.5 can be >>>> represented >>>> > exactly so it might be worthwhile to bash true 1s, -1,s, and 0s >>>> where >>>> > they belong in the table. >>>> > >>>> > Hearing that Max defaults to a ridiculously big table makes me >>>> wonder >>>> > though... first, is 2048 really enough (and at what point is >>>> there a >>>> > real performance penalty for bigger tables). And: not for this >>>> > release >>>> > but later perhaps, should 64-bit Pd use a bigger table? >>>> > >>>> > As I figure it, the 2048-point table differs from the true cosine, >>>> > absolute worst case, by (2pi/2048)^2 / 8, or about 2(-19.7) - >>>> > i.e., 19.7 >>>> > bit accuracy. But the error is dominated by an amplitude change >>>> (the >>>> > best-matching cosine to the line-segment approximation has >>>> amplitude >>>> > less than 1). Accounting for that and taking RMS error instead of >>>> > worst-case gives an error estimate 2.7 bits more optimistic: 22.4 >>>> > bits, >>>> > which is close to the accuracy of a 32-bit number. >>>> > >>>> > I don't have my RPI3 handy (I'm on the road) but I'm now >>>> wondering if >>>> > the default shouldn't be 4096, which would give us an additional 2 >>>> > bits >>>> > of goodness. Any opinions? >>>> > >>>> > cheers >>>> > >>>> > M >>>> > >>>> > On 6/5/24 9:35 PM, Matt Barber wrote: >>>> > > A couple of things: >>>> > > >>>> > > 1. I'm pretty sure any error in cos at pi and 2pi will be >>>> > smaller in >>>> > > double precision than float's epsilon, so I don't think that >>>> > there's >>>> > > any need to set -1.0 and 1.0 explicitly after all except to be >>>> > extra >>>> > > safe. However, at pi/2 and 3pi/2 the error is still larger than >>>> the >>>> > > minimum normal number, so it is worth setting the zero crossings >>>> > to 0.0. >>>> > > >>>> > > 2. For garray_dofo() there isn't a great way of using explicit >>>> > 0.0 at >>>> > > zero crossings without incurring an extra check, like don't add >>>> > to the >>>> > > sum if absolute value is less than e.g. 1.0e-10. For this, >>>> probably >>>> > > just using M_PI and incrementing integer phase like for the >>>> cosine >>>> > > table is enough. >>>> > > >>>> > > MB >>>> > > >>>> > > >>>> > > On Wed, Jun 5, 2024 at 2:20 PM Alexandre Torres Porres >>>> > > <[email protected]> wrote: >>>> > > >>>> > > Em qua., 5 de jun. de 2024 às 14:31, Matt Barber >>>> > > <[email protected]> escreveu: >>>> > > >>>> > > While we're at it, I think it would be worth tuning >>>> > > garray_dofo() to use the same so that sinesum and >>>> > > cosinesum have the same level of accuracy, guarantees of >>>> > > symmetry, etc. >>>> > > >>>> > > MB >>>> > > >>>> > > >>>> > > Good catch! In fact, I think this is a great opportunity to >>>> also >>>> > > fix this bug >>>> https://github.com/pure-data/pure-data/issues/371 >>>> > > >>>> > < >>>> https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/371__;!!Mih3wA!Gx7B-gwSgjsuIXmREh2__bBbYdt1d6pi29crpkLOOyltinVweZR3u6Q6vl9ItouugFy2oefgYhPlew$ >>>> > >>>> > > which is totally related. I just reopened >>>> > > https://github.com/pure-data/pure-data/issues/105 >>>> > > >>>> > < >>>> https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/105__;!!Mih3wA!Gx7B-gwSgjsuIXmREh2__bBbYdt1d6pi29crpkLOOyltinVweZR3u6Q6vl9ItouugFy2oedw4qUPfQ$ >>>> > >>>> > > as well as I'm still considering the table could/should be >>>> still >>>> > > "perfectly symmetric" considering 0 crossings and the >>>> start/end >>>> > > points. >>>> > > >>>> > > >>>> > > On Wed, Jun 5, 2024 at 12:52 PM Alexandre Torres Porres >>>> > > <[email protected]> wrote: >>>> > > >>>> > > For the record and sake of comparison, Cyclone uses >>>> > > a 16384 points table, and linear interpolation, >>>> > calculated >>>> > > with double precision. We did this because MAX >>>> documents >>>> > > it uses such a table, and we made it (well, Matt >>>> did) >>>> > > simetric. >>>> > > >>>> > > I see Pd is doing kind of the same, huh? linear >>>> > > interpolation on a table calculated with double >>>> > precision. >>>> > > >>>> > > I see SuperCollider mentions it uses 8192 points and >>>> > > linear interpolation on its oscillator. >>>> > > >>>> > > I guess MAX is exaggerating its table size a bit :) >>>> > but I >>>> > > wonder why Pd is still about to use a relatively >>>> smaller >>>> > > table size. I'm curious to know how much an >>>> increase in >>>> > > table size actually offers a better resolution and >>>> how >>>> > > much it ruins performance. For instance, I'm using >>>> the >>>> > > same as Cyclone in ELSE oscillators, could I just >>>> reduce >>>> > > it at least to 8192 points or even less and down to >>>> Pd's >>>> > > 2048 size worry free? >>>> > > >>>> > > Thanks >>>> > > >>>> > > >>>> > > >>>> > > Em qua., 5 de jun. de 2024 às 13:28, Alexandre >>>> Torres >>>> > > Porres <[email protected]> escreveu: >>>> > > >>>> > > Nice one Matt! >>>> > > >>>> > > Em qua., 5 de jun. de 2024 às 08:13, Christof >>>> Ressi >>>> > > <[email protected]> escreveu: >>>> > > >>>> > >> @Miller: what do you think? IMO we >>>> should >>>> > >> make the cos table as good as we can, >>>> so we >>>> > >> won't have any regrets :) >>>> > >> >>>> > > +1000!!! >>>> > > >>>> > >>>> >>>
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
