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

Matt Barber brbrofsvl at gmail.com
Sat Nov 21 20:24:00 CET 2015


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>
> An: "Christof Ressi" <christof.ressi at gmx.at>
> Cc: Pd-List <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>:
>
> 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]>
> An: "Roman Haefeli" <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]>
> 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]>:
> > 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]>:
>
> 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] 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]]
>  _______________________________________________ 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]]
> _______________________________________________
> 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/20151121/7e6da25e/attachment.html>


More information about the Pd-list mailing list