[PD] oscillators (osc~ / cycle~) not working well in FM?
Matt Barber
brbrofsvl at gmail.com
Sun Nov 22 15:59:55 CET 2015
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/79f13cca/attachment-0001.html>
More information about the Pd-list
mailing list