... with inlet~ and outlet~ obviously On Sun, Nov 22, 2015 at 9:59 AM, Matt Barber <brbrof...@gmail.com> wrote:
> This means we should be able to subtract out the DC in PD itself, as a > workaround. If it works, you could make an abstraction for modulating > oscillator: > > [inlet] > | > [osc~ $1] > | > [-~ 2.65309e-06] > | > [outlet] > > Seems stable so far to me. I'll run it for an hour to see. > > The correction for tabosc4~ would be a little more complex since it's size > dependent, but still easy enough. > > Thanks for the tip, Volker. > > > > On Sun, Nov 22, 2015 at 6:34 AM, volker böhm <vbo...@gmx.ch> wrote: > >> yes, this could easly be improved by not using phase accumulation to >> calculate the wavetable and by using something a little closer to pi for >> the phase increment. >> something like this (i'm looking at cos_maketable(void) in d_osc.c): >> >> float *fp, phase, phsinc = (2. * 3.1415926) / COSTABSIZE; >> ... >> for (i=0, fp = costab; i < COSTABSIZE+1; i++) >> fp[i] = cos(i*phasinc); >> >> >> and yes, if phsinc is defined as double that would even be a little >> better. >> >> >> On 22.11.2015, at 11:57, "Christof Ressi" <christof.re...@gmx.at> wrote: >> >> > 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 >> > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list