[PD] "good" phasor~ in B16.long-varispeed.pd not looping?

[William Huston]

I would really love it if someone could provide a sample patch
demonstrating how to load a long audio file, and be able to scrub
through it using onset.

I am utterly baffled by B16.long-varispeed.pd

Something as simple as Rafael Hernandez' patch here:
https://www.youtube.com/watch?v=boX0v54SqtU

PS: What is the status of PD Double?
I understand it could break a lot of things.

Would be nice if this could be done with perfect backward
compatibility with existing externals.
(Is this naive of me to think this is possible?)

Funny, I have grown to like the "bitcrush" style distortion
from using the existing single-precision method.

But the day I can load a 2 hour .(wav|mp3) file,
and be able to a) scrub through it effortlessly,
and b) be able to identify, store, and manipulate
in/out points down to a per-sample resolution,
I will be in heaven on earth!

BH




--
William Huston:  WilliamAHuston at gmail.com
Binghamton NY

*Public Service Mapping / Videography / Research / Education / Safety
Advocacy*
Blog <http://WilliamAHuston.blogspot.com> -- Facebook
<http://facebook.com/billhuston> -- Twitter
<http://twitter.com/WilliamAHuston>-- Youtube
<https://www.youtube.com/channel/UCGijK1amWOLglT3YeTyEBNQ?sub_congfirmation=1>
* -- Podcast Blog <https://billhustonpodcast.blogspot.com/>*
*Document collections*: VirtualPipelines
<http://TinyURL.com/VirtualPipelines> -- BHDCSDimockArchive
<http://bit.ly/BHDCSDimockArchive>
*Please support my work! -- *TinyURL.com/DonateToBillHuston





On Fri, Jan 3, 2020 at 7:31 PM Miller Puckette <msp at ucsd.edu> wrote:

> It's not intentional - I must never have checked whether looping worked.
>
> In fact, looping would only work if the begining of the table were copied
> to
> the end (at least 1/10 seconds worth, more if transposing up).  This needs
> updating.
>
> cheers
> M
>
> On Fri, Jan 03, 2020 at 10:50:22PM +0100, Peter P. wrote:
> > Hi list,
> >
> > I am trying to understand the B16.long-varispeed.pd patch that measures
> > a [phasor~]'s phase to calculate an onset which is to be sent into the
> > right inlet of a [tabread4~]. The patch shows a good example and a bad
> > one. Interestingly the [phasor~] in the bad one does produce looping
> > playback, while the onset value in the "good" example keeps increasing
> > beyond the end of the table. Perhaps this different behavior is intended?
> >
> > I am currently trying to adapt an abstraction of mine, which uses
> > [line~] to read a table from a certain start position to an end position
> > (also backwards) to use the method from the above example. Seems to be
> > quite a riddle...
> >
> > P
> >
> >
> >
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200104/e23cc600/attachment.html>