[PD] ipoke~ ?
jancsika at yahoo.com
Sun Jun 17 09:16:27 CEST 2012
What does Csound's vdelayxw do: mix or overwrite?
----- Original Message -----
> From: Matt Barber <brbrofsvl at gmail.com>
> To: katja <katjavetter at gmail.com>
> Cc: pd-list <pd-list at iem.at>
> Sent: Sunday, June 17, 2012 12:37 AM
> Subject: Re: [PD] ipoke~ ?
>>> 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
>>> 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
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
More information about the Pd-list