[PD] pd book sprint

Roman Haefeli reduzierer at yahoo.de
Wed Apr 1 11:21:44 CEST 2009



Von: Frank Barknecht <fbar at footils.org>
Gesendet: Montag, den 30. März 2009, 19:03:35 Uhr

> While the oscillators in s_osc.pd all go from -1 to 1, I don't really see why a
> triangle wave should not go from 0-1 as well. This may even be useful in
> certain applications. All it takes to convert it is a multiply-add. And isn't
> differentiating between ring modulation and amplitude modulation according to
> where the DC is old school analog thinking? ;) In Pd I prefer to think just
> about multiplications of one signal with another one.

i am not sure, if i can follow. the dc offset indeed makes a difference. and i don't think, there is much of a difference between analog and digital domain. if you want to control the amplitude of a sound signal, then you might prefer the 0-1 range. if it is to intended to be an audio signal itself, then you really want it to oscillate between -1 and 1 (this applies to a triangle, but not to a pwm square). 

not making that distinction can be quite troublesome. imagine a setup with many synth instruments runnning at the same time. one of them uses several instances of an oscillator, that isn't dc corrected. the more voices of that particular synth you have, the more dc offset you will add to the sum signal. because of that, you encounter bad distortion at a volume level much lower than you expected. not only that, the distortion is dependent on the number of voices used by the faulty synth. if you add enough dc offset, then you might not hear anything at all anymore.  also feedback delays won't work, since the dc will increase with every feedback cycle. 

i guess you already know this all, i just took the chance to sketch out, what can happen, if there wasn't taken care of removing dc-offset correctly. 

@derek: i think, that one shouldn't make a trade-off between simplicity/ease-of-understanding and correctness. it might seem pedantic to emphasize on dc-removal in such a tutorial, but when not doing so, many problems will arise from that. i also encounter, that even more experienced (pd-) people  sometimes don't fully understand what dc offset and its implications mean. this makes me want to put even more emphasis on the issue. what i mean to say, is that it might not help people,  when the aspect of dc-offset and dc-removal is left out. actually, i find pd is a very good and didactic tool to illustrate such problems. personally,  i very often experienced, that i didn't have to understand a certain aspect of dsp (or whatever field) beforehand, i. e. before i tried the implementation in pd. in contrary: trying things in pd helped me understand those concepts.

@[hip~] solution to remove dc-offset: this is not a real solution, because the amount of unwanted parts of the signal is dependent on the frequency setting of [hip~]. i mean it _does_ remove dc offset on the long run, but it might doesn't help or produces wierd results in certain situations. for instance, if you chain three modules in the following order: 

oscillator with dc
|
envelope generator
|
highpass filter

the result might contain unwanted very-low frequent parts. if you send that signal to a feedback delay, then you get similar issues as described above. in all cases, it is always best to do it 'pedantically' correct from the beginning and avoid dc offset overall. 

roman


      




More information about the Pd-list mailing list