Hi all --
Peter Brinkmann and Michael Goggins did some related work recently:
http://nettoyeur.noisepages.com/2010/10/doppler-effects-without-equations/
but back in the dark ages Barry Vercoe made a Music 11 ugen called 'pipadv' that added a signal into a delay line assuming the write location was continuous and could be stably differentiated (so that for each point of the delay line you could associate a fractional pposition in the incoming signal. He then interpolated to get fractional-indexed values of the incoming signal to correspond with successive sample locations in the delay line, turning the problem around backward.)
I've thought about this for a few hours but so far my only conclusion is that it's very interesting :)
Miller
On Sat, Jan 07, 2012 at 05:48:04PM +0100, katja wrote:
On Sat, Jan 7, 2012 at 2:23 PM, Mathieu Bouchard matju@artengine.ca wrote:
I don't think that [tabread4~] can be reversed so easily. I think that the most appropriate antialiased [tabwrite4~] would not be a mirror image of what [tabread4~] is.
Admittedly I did not have a clear idea of how writing at fractional speed could be conceived. Your detailed answer helped me to concentrate on the issues. Thanks, Mathieu.
A [tabwrite4~] is not comparable to [tabread4~] indeed, because writing is much more obliging than reading. Like you can read and skip chapters in a book, but you can't publish a book with chapters or pages missing, or print the pages over each other.
So the issue of fractional-speed-writing should really be solved as fractional resampling. I've been experimenting with chirp z-transform some years ago, and was surprised by the perfect interpolation which it can do. A block of audio can be blown up alias-free to any length, like with zero-padding but without the power-of-two ratio restriction. Downsampling likewise. Maybe I should write it into a Pd class. Certainly it won't be an easy job though.
Katja
It wouldn't necessarily write four values : making it write two values would be quite normal ; you'll want to tune its amount of «opaqueness» perhaps, and this will be a setting for which you will have no ideal default value ; and whatever it'll be, you probably won't like that it's not a mirror image of [tabread4~] or even of [tabread~].
This makes me think of [#remap_image] and [#store]. If I want to warp the coordinates of a picture in a nontrivial way, I can't loop over the source pixels and write them in the destination image, because this creates lots of holes. It doesn't tell what to fill the holes with. What [#remap_image] does (using the [#store] external) is to loop over destination pixels and choose where their data come from. This means that the warping function has to be inversed.
nontrivial examples : http://gridflow.ca/gallery/un_sur_z%C3%A8de.jpg http://gridflow.ca/gallery/patch_dans_patch_5.png http://gridflow.ca/gallery/patch_dans_patch_9.png
help : http://gridflow.ca/help/%23remap_image-help.html
But when the source data is a continuous flow, you can't index it as if it were a picture of pixels, because the flow of sound is unlimited and realtime.
IMHO, it's a hard problem. It looks like the kind of thing for which many situation-specific solutions are designed because there is no general way to make something that generally makes sense.
While writing 4 values, recently written values must be taken into account, not bluntly overwritten. So two existing values, x[n-2] and x[n-1], should be somehow integrated with new values, if the writing direction is positive.
Just think about constant speeds for now : if the index is a phasor moving at the same speed as [tabsend~] would, then it better act very similar to [tabsend~]. This is the first thing you ought to verify for any possible solution. Then you should look at what happens when using any other different constant speeds. Then if you are satisfied with what happens with all constant speeds, chances are that you will be satisfied with variable speeds.
 ______________________________________________________________________ | Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list