[PD] oscillators (osc~ / cycle~) not working well in FM?

Matt Barber brbrofsvl at gmail.com
Sun Nov 22 16:01:06 CET 2015 

... with inlet~ and outlet~ obviously

On Sun, Nov 22, 2015 at 9:59 AM, Matt Barber <brbrofsvl at gmail.com> wrote:

> 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 <vboehm at 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.ressi at 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.ressi at gmx.at>
>> >> An: "volker böhm" <vboehm at gmx.ch>
>> >> Cc: pd-list at 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.ressi at gmx.at>
>> >>> An: "volker böhm" <vboehm at gmx.ch>
>> >>> Cc: pd-list at 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" <vboehm at gmx.ch>
>> >>>> An: pd-list at iem.at
>> >>>> Cc: "Christof Ressi" <christof.ressi at 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.ressi at 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" <porres at gmail.com>
>> >>>>> An: "Christof Ressi" <christof.ressi at gmx.at>
>> >>>>> Cc: "Matt Barber" <brbrofsvl at gmail.com>, Pd-List <
>> pd-list at 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.ressi at 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" <brbrofsvl at gmail.com>
>> >>>>> An: "Christof Ressi" <christof.ressi at gmx.at>
>> >>>>> Cc: "Alexandre Torres Porres" <porres at gmail.com>, Pd-List <
>> pd-list at 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.ressi at 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" <porres at gmail.com[porres at gmail.com]>
>> >>>>> An: "Christof Ressi" <christof.ressi at gmx.at[christof.ressi at gmx.at]>
>> >>>>> Cc: Pd-List <pd-list at lists.iem.at[pd-list at 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.ressi at gmx.at[
>> christof.ressi at 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" <porres at gmail.com[porres at gmail.com][
>> porres at gmail.com[porres at gmail.com]]>
>> >>>>> An: "Roman Haefeli" <reduzent at gmail.com[reduzent at gmail.com][
>> reduzent at gmail.com[reduzent at gmail.com]]>
>> >>>>> Cc: "pd-list at lists.iem.at[pd-list at lists.iem.at][
>> pd-list at lists.iem.at[pd-list at lists.iem.at]]" <pd-list at lists.iem.at[
>> pd-list at lists.iem.at][pd-list at lists.iem.at[pd-list at 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 <
>> porres at gmail.com[porres at gmail.com][porres at gmail.com[porres at 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 <reduzent at gmail.com[
>> reduzent at gmail.com][reduzent at gmail.com[reduzent at 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 at lists.iem.at[Pd-list at lists.iem.at][Pd-list at lists.iem.at[
>> Pd-list at 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 at lists.iem.at[Pd-list at lists.iem.at][Pd-list at lists.iem.at[
>> Pd-list at 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 at lists.iem.at[Pd-list at 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 at lists.iem.at mailing list
>> >>>>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>> >>>>
>> >>>>
>> >>>
>> >>> _______________________________________________
>> >>> Pd-list at lists.iem.at mailing list
>> >>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>> >>>
>> >>
>> >> _______________________________________________
>> >> Pd-list at lists.iem.at mailing list
>> >> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>> >>
>>
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151122/41e2112b/attachment-0001.html>

More information about the Pd-list mailing list