Including the case of Pd Double @ PD_FLOAT_PRECISION == 32
On Saturday, November 21, 2015 2:40 PM, Jonathan Wilkes
<jancs...@yahoo.com> wrote:
What's Pd Double do in this case?
-Jonathan
On Saturday, November 21, 2015 2:25 PM, Matt Barber <brbrof...@gmail.com>
wrote:
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>
An: "Christof Ressi" <christof.re...@gmx.at>
Cc: Pd-List <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>:
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]>
An: "Roman Haefeli" <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]>
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]>:
> 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]>:
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] 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]]
_______________________________________________
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]]
_______________________________________________
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
