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