>> 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
