[PD] ipoke~ ?

Matt Barber brbrofsvl at gmail.com
Sun Jun 17 06:37:20 CEST 2012

>> As far as mixing vs. overwriting is concerned, that actually depends
>> on what it's trying to model. Overwriting is probably right for a
>> looper, but mixing is right for a recording of a moving sound source -
>> and because [poke~] doesn't interpolate it's not an issue (it wouldn't
>> be useful to model a moving sound source).
> But 'approach B' condenses 4 read samples into 1 write sample, so
> basically it does the same as [poke]: writing one sample at a time.
> There is no need for mixing internally. If you want to mix, it can be
> done externally. In my view, a Pd object need not internalize
> functions that can be done externally, unless there is a huge
> performance penalty involved.

Here is one use case where mixing as part of the function would be
useful. Imagine you're trying to model a sound source moving at mach+
speeds -- let's say it starts 500 meters away from the microphone and
plays for 3 seconds, and then it moves toward the microphone at twice
the speed of sound until it gets two meters away, and then (against
any sensible law of inertia) it turns on a dime and moves away from
the mic again at .25 the speed of sound.

Much of the sound it generates after it makes the turn will reach the
microphone before the sound it was making when it started its approach
toward the microphone reaches the mic (since the source overtakes its
own previous sound).

Moving toward the mic faster than sound is analogous to moving
backwards in the table, and for it to be correct it needs to mix
rather than overwrite, and it would be very difficult to maintain
separate copies of everything and mix it elsewhere in Pd for anything
where the control signal is less predictable.

So, maybe this is a totally exceptional case that isn't worth caring
about, but I'd like to note that this kind of thing (not necessarily
faster-than-speed sound, but the physical model) is exactly the
motivation for the movable write into a delay line used in room
simulation and/or distance encoding in ambisonics, and I think there
ought to be at least a switch at the end of the creation argument line
that only interested people would use and everyone else can forget
about (that is, if "approach B" turns out to work well in the first


More information about the Pd-list mailing list