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.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?
>
> 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
>
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
