[PD] Feedback discussion
Mathieu Bouchard
matju at artengine.ca
Tue Sep 15 22:00:09 CEST 2009
On Tue, 15 Sep 2009, Derek Holzer wrote:
> as you probably discovered, you need to use a send~/receive~ pair or
> other type of one-block delay to make any kind of feedback in Pd
You don't need it to be one block...?
> For one, feedback in the digital realm is never instantaneous,
Instantaneousness is a myth. It does not exist in nature. If you ever
wondered why computer clock speeds stopped increasing recently... well,
that's the reason. but in the audio world, in which everything is in kHz,
you wouldn't notice that often, because the scale of hearing is much
larger than the scale of signal propagation.
> because no code can compute it's output using that exact same output as
> its input (discrete/sampled time).
Use Mathematica. You will find out that it can figure out simultaneity
equations using algebraïc manipulation, which is a digital-only concept.
The only way you can compute actual instantaneous equations in analogue
gear is if you use your analogue gear to build enough digital gear to be
able to run Mathematica. But for audio, a straight mapping of signal
theory might appear instantaneous in almost all cases... due to scale.
> In the analog realm, as in real life, things can and do simultaneously
> affect each other (continuous time).
This analog realm, just like this real life, are completely foreign to the
physics of the last 100 years.
> This makes sense since a filter is in fact a small feedback system of
> it's own which cancels out or reinforces various phases of a wave!
Not all filters are feedback systems... for example, [rpole~] uses
feedback, but [rzero~] doesn't.
> So this was the second turn-off from digital feedback systems--that I
> couldn't always rely on them to work!
Ow, I don't know how you can rely on your analogue gear to work... I
suppose you keep room temperature very close to constant, and you put the
whole thing in a huge faraday cage, etc. One big reason for using digital
gear is that it's so much more predictable.
> Most filters or delays in Pd, for example, throw a "nan" error at that
> point and the signal chain breaks down.
If it does a NaN in the digital realm, it does a NaN also in signal
theory, which means it does a NaN in Maxwell theory, which means Maxwell
theory can't explain it, yet something happens. Therefore Maxwell theory
is at least a bit off from the real world, and so this is another example
of why you shouldn't confuse signal theory and real world.
I figured this out in grade 13 when they showed us Maxwell equations and
there were derivatives of things like resistance, but while you plug a
wire, the resistance changes suddenly, and this causes a NaN in the
derivative, and Maxwell theory offers no way to figure out what will
happen at that time. Obviously, the teacher and the book both conveniently
worked around those hurdles by ignoring them... provided no-one asks how
to compute the voltage of the spark that comes out by plugging a certain
wire in a certain circuit.
> Frank Barknecht posted a waveshaper to do soft clipping somewhere in the
> archives once, that might be an interesting patch to look at, since what
> it does is gradually "taper off" values as they approach the max/min
> values, instead of "hard clipping" them as the [clip~] object would.
I mention [expr~ tanh($v1)] rather often (?), and I'm not the first one to
use it. I suspect that it's rather close to how capacitors saturate, but
still somewhat off... (I think I recall capacitors saturate more like
negative exponentials...)
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
More information about the Pd-list
mailing list