What does Csound's vdelayxw do: mix or overwrite?
-Jonathan
----- Original Message -----
From: Matt Barber brbrofsvl@gmail.com To: katja katjavetter@gmail.com Cc: pd-list pd-list@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
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 place).
Matt
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list