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.re...@gmx.at> > An: "volker böhm" <vbo...@gmx.ch> > Cc: pd-l...@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" <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 > _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
