On Sat, Jan 7, 2012 at 2:23 PM, Mathieu Bouchard <[email protected]> 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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
