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

Reply via email to