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@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
*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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list