This means we should be able to subtract out the DC in PD itself, as a workaround. If it works, you could make an abstraction for modulating oscillator:
[inlet] | [osc~ $1] | [-~ 2.65309e-06] | [outlet] Seems stable so far to me. I'll run it for an hour to see. The correction for tabosc4~ would be a little more complex since it's size dependent, but still easy enough. Thanks for the tip, Volker. On Sun, Nov 22, 2015 at 6:34 AM, volker böhm <vbo...@gmx.ch> wrote: > yes, this could easly be improved by not using phase accumulation to > calculate the wavetable and by using something a little closer to pi for > the phase increment. > something like this (i'm looking at cos_maketable(void) in d_osc.c): > > float *fp, phase, phsinc = (2. * 3.1415926) / COSTABSIZE; > ... > for (i=0, fp = costab; i < COSTABSIZE+1; i++) > fp[i] = cos(i*phasinc); > > > and yes, if phsinc is defined as double that would even be a little better. > > > On 22.11.2015, at 11:57, "Christof Ressi" <christof.re...@gmx.at> wrote: > > > Hmmm... so phaseincr is not as precise as it could be. And because phase > is incremented by phaseincr for every point of the wavetable, it is clear > that large wavetables are more asymmetric than short ones because the > errors add up. Still, a large wavetable done with cosinesum seems to be > more precise than the standard wavetable for [osc~] and [cos~] because it's > done with doubles and not with floats (cos() actually expects doubles as > argument). > > > > static void garray_dofo(t_garray *x, long npoints, t_float dcval, > > int nsin, t_float *vsin, int sineflag) > > { > > double phase, phaseincr, fj; > > int yonset, i, j, elemsize; > > > > ... > > > > phaseincr = 2. * 3.14159 / npoints; > > for (i = 0, phase = -phaseincr; i < array->a_n; i++, phase += > phaseincr) > > { > > double sum = dcval; > > if (sineflag) > > for (j = 0, fj = phase; j < nsin; j++, fj += phase) > > sum += vsin[j] * sin(fj); > > else > > for (j = 0, fj = 0; j < nsin; j++, fj += phase) > > sum += vsin[j] * cos(fj); > > *((t_float *)((array->a_vec + elemsize * i)) + yonset) > > = sum; > > } > > garray_redraw(x); > > } > > > > > >> Gesendet: Sonntag, 22. November 2015 um 11:40 Uhr > >> Von: "Christof Ressi" <christof.re...@gmx.at> > >> An: "volker böhm" <vbo...@gmx.ch> > >> Cc: pd-l...@iem.at > >> Betreff: Re: [PD] oscillators (osc~ / cycle~) not working well in FM? > >> > >> Ah, what kind of strikes me as odd is that in the routine garray_dofo > it says: > >> > >> double phase, phaseincr, fj; > >> > >> ... > >> > >> phaseincr = 2. * 3.14159 / npoints; > >> > >> Because phaseincr had been declared as double, Pi could have been > written with a lot more decimal places. Or am I missing something? > >> > >> > >> > >>> Gesendet: Sonntag, 22. November 2015 um 11:30 Uhr > >>> Von: "Christof Ressi" <christof.re...@gmx.at> > >>> An: "volker böhm" <vbo...@gmx.ch> > >>> Cc: pd-l...@iem.at > >>> Betreff: Re: [PD] oscillators (osc~ / cycle~) not working well in FM? > >>> > >>>>> the "cos_maketable(void)" in d_osc.c produces a waveform which is > slightly asymmetric, i.e. it has a tiny DC offset. > >>> > >>> Thanks! That's exactly what I could observe when nulling [osc~] and > [tabosc4~]. Is there a reason for the wavetable being slightly asymmetric? > >>> Looking at the source code, cos_maketable (in d_osc.c) does the > calculation in floats whereas garray_dofo (in g_array.c) uses doubles, so > it's no wonder that it's more precise. Still it's not perfect (I guess it > can't) and I still don't understand why an 8-point wavetable yeilds better > results than a 8192-point table... > >>> > >>> And how does SC achieve such stable FM!? > >>> > >>> Btw, I tried to use linear interpolation instead of 4-point > interpolation and there was no noticeable difference. > >>> > >>> > >>> > >>> > >>> > >>>> Gesendet: Sonntag, 22. November 2015 um 10:44 Uhr > >>>> Von: "volker böhm" <vbo...@gmx.ch> > >>>> An: pd-l...@iem.at > >>>> Cc: "Christof Ressi" <christof.re...@gmx.at> > >>>> Betreff: Re: [PD] oscillators (osc~ / cycle~) not working well in FM? > >>>> > >>>> hi, > >>>> i think the timbre change in the FM example is due to a less than > ideal cosine wavetable which is used for osc~ (and cos~ etc.). > >>>> the "cos_maketable(void)" in d_osc.c produces a waveform which is > slightly asymmetric, i.e. it has a tiny DC offset. > >>>> this in return, causes the timbre shift when used in an FM context > (asymmetric FM). > >>>> vb > >>>> > >>>> > >>>> > >>>> On 22.11.2015, at 10:30, "Christof Ressi" <christof.re...@gmx.at> > wrote: > >>>> > >>>>>>> I have to say I didn't see much improvement with 8192 point > wavetable and tabosc4~ > >>>>> > >>>>> In your patch you substituted the carrier but the problem is the > modulator. Once you use [tabosc4~] as the modulator, the drift is minimal > (but it's still there). Actually it doesn't matter if you use [osc~] or > [tabosc4~] as the carrier. (See my attached patch). > >>>>> > >>>>> I tested it in SC and you're right, I couldn't see any change in the > waveform either - even after a couple of minutes. > >>>>> > >>>>> Some weird things so far: > >>>>> 1) [tabosc4~] is a better modulator than [osc~] > >>>>> 1) 8-points are better than 8192-points. > >>>>> 2) [osc~] and [tabosc4~] will never null out, so [osc~] is > implemented differently (but how?) > >>>>> > >>>>> Some interesting side note: SC actually doesn't use 4-point > interpolation for wavetable lookup but rather a form of linear > interpolation: > >>>>> http://doc.sccode.org/Classes/Wavetable.html > >>>>> http://doc.sccode.org/Classes/Osc.html > >>>>> > >>>>> Still I'm asking myself if Max and SC might do some internal > calculations with higher precision than Pd... > >>>>> > >>>>> Maybe Miller can help us with this? > >>>>> > >>>>> > >>>>> > >>>>> Gesendet: Sonntag, 22. November 2015 um 05:11 Uhr > >>>>> Von: "Alexandre Torres Porres" <por...@gmail.com> > >>>>> An: "Christof Ressi" <christof.re...@gmx.at> > >>>>> Cc: "Matt Barber" <brbrof...@gmail.com>, Pd-List < > pd-list@lists.iem.at> > >>>>> Betreff: Re: Re: [PD] oscillators (osc~ / cycle~) not working well > in FM? > >>>>> > >>>>> well, I was trying [phasor~] + [cos~] instead of [osc~] and same > thing happens, so whatever is the deal with [osc~] seems to be also with > that. > >>>>> > >>>>> I have to say I didn't see much improvement with 8192 point > wavetable and tabosc4~ > >>>>> > >>>>> check my test patch, both behave the same way > >>>>> > >>>>> and, again, in SC or max is just perfect, anyone tried it? > >>>>> > >>>>> > >>>>> SC code again: > >>>>> > >>>>> {SinOsc.ar(SinOsc.ar(100, 0, 100 * 2pi), pi/2)}.scope > >>>>> > >>>>> cheers > >>>>> > >>>>> 2015-11-21 19:54 GMT-02:00 Christof Ressi <christof.re...@gmx.at>:I've > checked if there's a possible time drift between [osc~] and [tabosc4~] and > there's clearly none (I had them both run in parallel for several minutes > and compared the results). > >>>>> Then I did a testing patch (see attachment) where I take the > difference between the output of [osc~] and three [tabosc4~] objects (with > various table sizes). While the difference between the various [tabosc4~] > objects shows a nice periodicity and symmetry, the difference between > [osc~] and any [tabosc4~] object is somehow periodic but it's not symmetric > (and it's much larger). Does anyone understand how [osc~] is actually > implemented and why it generates a different output than [tabosc4~]? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Gesendet: Samstag, 21. November 2015 um 20:24 Uhr > >>>>> Von: "Matt Barber" <brbrof...@gmail.com> > >>>>> An: "Christof Ressi" <christof.re...@gmx.at> > >>>>> Cc: "Alexandre Torres Porres" <por...@gmail.com>, Pd-List < > pd-list@lists.iem.at> > >>>>> Betreff: Re: [PD] oscillators (osc~ / cycle~) not working well in FM? > >>>>> > >>>>> Try it with an 8-point table and [tabosc4~]. It's still far more > stable than [osc~]. > >>>>> > >>>>> > >>>>> > >>>>> On Sat, Nov 21, 2015 at 1:50 PM, Christof Ressi < > christof.re...@gmx.at> wrote:I've found the reason! Looking at the Pd > source code (d_osc.c and m_pd.h) [osc~] seems to read from a 512 (1<<9) > point wavetable (defined by LOGCOSTABSIZE and COSTABSIZE in m_pd.h), > whereas SuperCollider's SinOsc uses 8192 points. (Both programs do their > audio math with 32-bit floats.) > >>>>> So I tried to substitute [osc~] with [tabosc4~] reading from a 8192 > point wavetable (done with a simple cosinesum) - and the result is far more > stable (although not perfect)! I think you can't really prevent this kind > of drift with FM, although you can keep it very small by using very large > wavetables. The better solution, however, is using PM, as you've discovered > anyway. > >>>>> > >>>>> > >>>>> Gesendet: Samstag, 21. November 2015 um 19:12 Uhr > >>>>> Von: "Alexandre Torres Porres" <por...@gmail.com[por...@gmail.com]> > >>>>> An: "Christof Ressi" <christof.re...@gmx.at[christof.re...@gmx.at]> > >>>>> Cc: Pd-List <pd-list@lists.iem.at[pd-list@lists.iem.at]> > >>>>> Betreff: Re: Re: [PD] oscillators (osc~ / cycle~) not working well > in FM? > >>>>> > >>>>>> Does this make sense? :-D > >>>>> > >>>>> yeah, I kinda had the same idea > >>>>> > >>>>>> Can anyone explain why this kind doesn't in SC or Max? > >>>>> > >>>>> that what I'd really love to know > >>>>> > >>>>> here's my SC code that relates to my first example patch I posted > here > >>>>> > >>>>> > >>>>> // 0Hz FM > >>>>> {SinOsc.ar(SinOsc.ar(100, 0, 100 * 2pi), pi/2)}.scope > >>>>> > >>>>> quite stable > >>>>> > >>>>> 2015-11-21 15:47 GMT-02:00 Christof Ressi <christof.re...@gmx.at[ > christof.re...@gmx.at]>: > >>>>> > >>>>> Hey Alexander, that's very interesting! What's funny: when using > [metro] + [vline~] instead of [phasor~], the drift is clearly slower. As > you noted, PM seems to be stable (It is noteworthy that DX7 actually uses > PM for better stability). > >>>>> > >>>>> My guess it, it has something to do with rounding errors. And I can > somehow intuitively see how this will affect FM but not PM: > >>>>> > >>>>> Let's imagine a huge truck on a highway. On the truck is another car > which can move forwards and backwards. And then there's a motercycle going > at a fixed speed. > >>>>> > >>>>> FM -> The car would remain fixed on the truck and someone would > press and release the gas pedal of the truck periodically (starting from > the same speed as the motercycle). If the amount of pressure/relief is not > 100% precise, you can't really tell where exactly the car+truck will be > after a couple of miles, even if the timing of manipulating the gas pedal > is 100% exact, because small errors in speed will immediately result in > small but lasting errors in location. So there will probably be a slow > drift over time between the truck+car and the motercycle. > >>>>> > >>>>> PM -> The truck moves at a fixed speed (same as the motorcycle) > while the car on the truck goes forwards and backwards at a fixed > intervall. The car is guaranteed to be in the middle of truck every N > seconds. So even if the movement of the car might not be perfect, the > location is 100% predictable at least every N*k seconds and this means that > it will stay in phase with the motorcycle. > >>>>> > >>>>> Does this make sense? :-D > >>>>> > >>>>> Can anyone explain why this kind doesn't in SC or Max??? (I didn't > test it myself) Larger look-up tables? More precision? > >>>>> > >>>>> > >>>>> > >>>>> Gesendet: Samstag, 21. November 2015 um 17:06 Uhr > >>>>> Von: "Alexandre Torres Porres" <por...@gmail.com[por...@gmail.com][ > por...@gmail.com[por...@gmail.com]]> > >>>>> An: "Roman Haefeli" <reduz...@gmail.com[reduz...@gmail.com][ > reduz...@gmail.com[reduz...@gmail.com]]> > >>>>> Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at > [pd-list@lists.iem.at]]" <pd-list@lists.iem.at[pd-list@lists.iem.at][ > pd-list@lists.iem.at[pd-list@lists.iem.at]]> > >>>>> Betreff: Re: [PD] oscillators (osc~ / cycle~) not working well in FM? > >>>>> > >>>>> By the way, I was wondering and thinking if this was a particularity > of the "0Hz carrier FM", that is: a FM patch with no carrier frequency. But > I tried other regular FM patches with a carrier signal and could see that > it didn't keep static as well. > >>>>> > >>>>> On the other hand, the same patch implemented as Phase Modulation > (PM) maintains a static waveform in Pd. > >>>>> > >>>>> In my last example, the patch I had as "waveshaping" could be > thought of as a "0hz PM" patch. > >>>>> > >>>>> Now, I tested the PM stability with the [phasor~] + [cos~] > architecture and also with [cycle~]. > >>>>> > >>>>> The FM instability happened with both [osc~] and [cycle~]. > >>>>> > >>>>> In Max, a FM patch with [cycle~] is stable. > >>>>> > >>>>> In short, there's something fishy with FM in Pd... > >>>>> > >>>>> cheers > >>>>> > >>>>> 2015-11-21 13:25 GMT-02:00 Alexandre Torres Porres <por...@gmail.com > [por...@gmail.com][por...@gmail.com[por...@gmail.com]]>: > >>>>>> Can you elaborate? > >>>>> > >>>>> Not easily I'm afraid, so I'll try to keep it simple: it's a > demonstration on the relationship between FM and waveshaping, compare now > both patches in my new example. The waveshaping does not change through > time. > >>>>> > >>>>> But let me attempt to reason why it should keep static - it's like > any other FM patch, once you have set the parameters, the waveform must be > static and not change in time. My tests with supercollider and Max had a > good result (waveform kept static). I also tried in Pd with cycle~ and in > the newest vanilla. > >>>>> > >>>>> cheers > >>>>> > >>>>> > >>>>> 2015-11-21 11:26 GMT-02:00 Roman Haefeli <reduz...@gmail.com[ > reduz...@gmail.com][reduz...@gmail.com[reduz...@gmail.com]]>: > >>>>> > >>>>> On Sat, 2015-11-21 at 02:59 -0200, Alexandre Torres Porres wrote: > >>>>>> howdy, attached there's a patch where I was experimenting with FM > >>>>>> > >>>>>> > >>>>>> the waveform shouldn't change with time, but it does. Give it a > while > >>>>>> though, 30 seconds is enough to hear a change in tone quality, then > >>>>>> resseting the oscillator phase brings it back to where it was > >>>>>> > >>>>>> > >>>>>> don't know why it does come out of phase, an equivalent patch in SC > >>>>>> and Max does not get out of phase... > >>>>> > >>>>> I hear and see what you mean. Interesting question. Frankly, I don't > >>>>> quite understand why it is expected to stay in phase. Can you > elaborate? > >>>>> > >>>>> Roman > >>>>> > >>>>> _______________________________________________ > >>>>> Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[ > Pd-list@lists.iem.at]] mailing listUNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]]][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]]]] > >>>>> _______________________________________________ Pd-list@lists.iem.at > [Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] > mailing list UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]]][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]]]] > >>>>> > >>>>> _______________________________________________ > >>>>> Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > >>>>> UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]] > >>>>> <FM-test-3-reply.pd>_______________________________________________ > >>>>> Pd-list@lists.iem.at mailing list > >>>>> UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> Pd-list@lists.iem.at mailing list > >>> UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >>> > >> > >> _______________________________________________ > >> Pd-list@lists.iem.at mailing list > >> UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >> > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list