[PD] oscillators (osc~ / cycle~) not working well in FM?
brbrofsvl at gmail.com
Sun Nov 22 22:32:53 CET 2015
Yeah, so all that really needs to be done is to force symmetry by copying
the 0-pi phase inverted to the pi-2pi phase + guard points for [tabosc4~].
I did that and it's been stable for 3.5 hours. It wouldn't be too hard to
fix this in the Pd source; it would be a marked improvement to [osc~] even
with the 512-pt table and linear interpolation.
On Sun, Nov 22, 2015 at 12:43 PM, Matt Barber <brbrofsvl at gmail.com> wrote:
> OK, subtracting out the DC is more stable, but still deteriorates after a
> bit, since the exact value likely changes with frequency due to
> interpolation. So the solution is going to have to be in writing the table.
> We can do it in Pd but we're hampered by the six-digit limit on specifying
> 2pi directly as a float. The most accurate pi I can think of for feeding
> through [cos] is [0 -1( -- [atan2]. [cos] uses the cosf() function from C,
> which expects floats instead of doubles, so hopefully the symmetry is
> better. I'm going to try it for a while and write back.
> On Sun, Nov 22, 2015 at 11:16 AM, Roman Haefeli <reduzent at gmail.com>
>> On Sun, 2015-11-22 at 10:44 +0100, volker böhm wrote:
>> > 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
>> Well spotted.
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list