The thing I'm really afraid of is:
Do subpatches with several [phasor~] used as a audiosignals produce a different result as intended without summing up in total over "1". Especially as in my cases where I'm using lots of [phasor~] mostly for amplitude modulation and most of the time they are not turned down in level.
Ingo
Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag von Ingo Gesendet: Dienstag, 23. November 2010 10:42 An: pd-list@iem.at Betreff: [PD] Strange behavior between [phasor~] and [creb/blosc~]
Hi everybody,
I just noticed a very strange behaviour concerning [phasor~].
It started when I wanted to replace [phasor~] with [creb/blosc~]. Normally they should sound pretty much the same except for the obvious aliasing problem of [phaser~]. Then I noticed that in some cases they didnt sound the same and in others they did. I finally found out that it had to do with the level going over 1 - only while being doubled.
While [creb/blosc~] sounds the same no matter if I boost the levels higher than 1 [phasor~] starts to cancle its sound. With a single [phasor~] its no problem but two of them will give you trouble. Since Pd is working with 32 bit float this shouldnt really happen and doesnt with [creb/blosc~].
Can anybody explain this? I have my test patch attached.
Ingo
Did you try graphing the output of the combined [phasor~] objects? To me, it seems likely that the lack of a zero-crossing in the [phasor~] waveform would create a large amount of DC offset, and perhaps that is what you are hearing. [creb/blosc~], [osc~] and pretty much any other audio waveform generator all have mostly equal amounts of positive and negative energy in their waveforms. Only [phasor~] is the weird exception and wasn't even designed to be used as signal source anyways. I'm quite sure it was mainly intended for use in driving [tabread~] objects.
D.
On 11/23/10 2:40 PM, Ingo wrote:
Do subpatches with several [phasor~] used as a audiosignals produce a different result as intended without summing up in total over "1".
Hi Derek,
that's it !!! I just subtracted 0.5 from the [phasor~] outlet and now it behaves as expected. Thank you!
Now I have to find all the [phasor~] objects in my patches und change it there. Using [blosc~] is just too expensive for simply producing some slight "dirt" modulations.
Ingo
-----Ursprüngliche Nachricht----- Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag von
Derek
Holzer Gesendet: Dienstag, 23. November 2010 14:49 An: pd-list@iem.at Betreff: Re: [PD] Strange behavior between [phasor~] and [creb/blosc~]
Did you try graphing the output of the combined [phasor~] objects? To me, it seems likely that the lack of a zero-crossing in the [phasor~] waveform would create a large amount of DC offset, and perhaps that is what you are hearing. [creb/blosc~], [osc~] and pretty much any other audio waveform generator all have mostly equal amounts of positive and negative energy in their waveforms. Only [phasor~] is the weird exception and wasn't even designed to be used as signal source anyways. I'm quite sure it was mainly intended for use in driving [tabread~]
objects.
D.
On 11/23/10 2:40 PM, Ingo wrote:
Do subpatches with several [phasor~] used as a audiosignals produce a different result as intended without summing up in total over "1".
-- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 113: "Make a blank valuable by putting it in an exquisite frame"
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
On Tue, 2010-11-23 at 15:18 +0100, Ingo wrote:
Hi Derek,
that's it !!! I just subtracted 0.5 from the [phasor~] outlet and now it behaves as expected. Thank you!
Now I have to find all the [phasor~] objects in my patches und change it there. Using [blosc~] is just too expensive for simply producing some slight "dirt" modulations.
If you're after a cheap band-limited saw generator, check this out: https://github.com/reduzent/pd-bloscabs
It's pure vanilla and cpu-wise not much more expensive than [tabosc4~]. I don't know, how the creb algorithm works, but I still had clearly audible anti-aliasing artefacts when trying out [creb/blosc~ saw].
Roman
Have a look here:
http://en.flossmanuals.net/PureData/DCOffset
My basic formula is
[*~ 2] | [-~ 1]
Best! D.
On 11/23/10 3:18 PM, Ingo wrote:
Hi Derek,
that's it !!! I just subtracted 0.5 from the [phasor~] outlet and now it behaves as expected. Thank you!
Now I have to find all the [phasor~] objects in my patches und change it there. Using [blosc~] is just too expensive for simply producing some slight "dirt" modulations.
Ingo
-----Ursprüngliche Nachricht----- Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag von
Derek
Holzer Gesendet: Dienstag, 23. November 2010 14:49 An: pd-list@iem.at Betreff: Re: [PD] Strange behavior between [phasor~] and [creb/blosc~]
Did you try graphing the output of the combined [phasor~] objects? To me, it seems likely that the lack of a zero-crossing in the [phasor~] waveform would create a large amount of DC offset, and perhaps that is what you are hearing. [creb/blosc~], [osc~] and pretty much any other audio waveform generator all have mostly equal amounts of positive and negative energy in their waveforms. Only [phasor~] is the weird exception and wasn't even designed to be used as signal source anyways. I'm quite sure it was mainly intended for use in driving [tabread~]
objects.
D.
On 11/23/10 2:40 PM, Ingo wrote:
Do subpatches with several [phasor~] used as a audiosignals produce a different result as intended without summing up in total over "1".
-- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 113: "Make a blank valuable by putting it in an exquisite frame"
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Yes, Derek,
that formula makes absolutely sense. The funny thing is that the level with the - 0.5 was identical with [creb/blosc~]. It should have been half the level. Strange!
Ingo
-----Ursprüngliche Nachricht----- Von: Derek Holzer [mailto:derek@umatic.nl] Gesendet: Dienstag, 23. November 2010 19:08 An: Ingo Cc: pd-list@iem.at Betreff: Re: AW: [PD] Strange behavior between [phasor~] and [creb/blosc~]
Have a look here:
http://en.flossmanuals.net/PureData/DCOffset
My basic formula is
[*~ 2] | [-~ 1]
Best! D.
On 11/23/10 3:18 PM, Ingo wrote:
Hi Derek,
that's it !!! I just subtracted 0.5 from the [phasor~] outlet and now
it
behaves as expected. Thank you!
Now I have to find all the [phasor~] objects in my patches und change it there. Using [blosc~] is just too expensive for simply producing some
slight
"dirt" modulations.
Ingo
-----Ursprüngliche Nachricht----- Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag
von
Derek
Holzer Gesendet: Dienstag, 23. November 2010 14:49 An: pd-list@iem.at Betreff: Re: [PD] Strange behavior between [phasor~] and [creb/blosc~]
Did you try graphing the output of the combined [phasor~] objects? To me, it seems likely that the lack of a zero-crossing in the [phasor~] waveform would create a large amount of DC offset, and perhaps that is what you are hearing. [creb/blosc~], [osc~] and pretty much any other audio waveform generator all have mostly equal amounts of positive and negative energy in their waveforms. Only [phasor~] is the weird exception and wasn't even designed to be used as signal source anyways. I'm quite sure it was mainly intended for use in driving [tabread~]
objects.
D.
On 11/23/10 2:40 PM, Ingo wrote:
Do subpatches with several [phasor~] used as a audiosignals produce a different result as intended without summing up in total over "1".
-- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 113: "Make a blank valuable by putting it in an exquisite frame"
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
-- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 101: "It is simply a matter of work"
-
Derek Holzer -
Ingo -
Roman Haefeli