[PD] [tabwrite4~], is it possible at all?

[katja]

On Sat, Jan 7, 2012 at 2:23 PM, Mathieu Bouchard <matju at 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