[PD] [tabwrite4~], is it possible at all?
msp at ucsd.edu
Sun Jan 8 21:01:02 CET 2012
Hi all --
Peter Brinkmann and Michael Goggins did some related work recently:
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 :)
On Sat, Jan 07, 2012 at 05:48:04PM +0100, katja wrote:
> 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.
> > 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
More information about the Pd-list