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

Alexandre Torres Porres porres at gmail.com
Sun Nov 22 06:22:13 CET 2015


also tried in Max with [phasor~] + [cos~]

all fine

2015-11-22 2:11 GMT-02:00 Alexandre Torres Porres <porres at gmail.com>:

> 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]]]
>>  _______________________________________________ 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]]]
>> _______________________________________________
>> 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]
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151122/5fe542db/attachment.html>


More information about the Pd-list mailing list