Hi there,

When my twins were born I suddenly had a lot less time for development. :)

The biggest issue we found was in taking care of aliasing when the write pointer moved slower than one point per sample. The easiest way is to keep a running average of input samples between writes, but it's not the best filter. We'd looked at a number of ways of doing it, including writing a filter kernel into adjacent samples (I believe this is what csound's vdelayxw opcode does). I remember Chuck had been working on that part of it when I bowed out never to get a full night's sleep again.

We'd talked also about using the same engine for a variable delwrite~ of sorts, which could be used for doppler shifts where the listener is stationary and the sources move, but that never got off the ground. The output of such an object would not need any access to Pd's delay architecture to work.

Matt

On Mon, Jul 19, 2021 at 5:23 AM Julian Brooks <jbeezez@gmail.com> wrote:
Hi all,

Yes, as stated -- ipoke~ is definitely implemented.
@Peter P. how you getting on with it? There's a more recent version too, with some additional classes and tests that @katja implemented.
There's also an experimental ipoke4~built that's not short of complete (with more input from Katja, @Matt Barber & @Charles Z Henry ) but doesn't yet include help files, though there are various tests/comparisons. I'd be happy to send it to you as a dm P if you're interested but it's not quite ready for wider sharing as of yet. Thanks too to Fred Jan @fjkraan@xs4all.nl for the pd lib builder version. The experimental version of the lib doesn't yet have this but Katja's makefile works good for me.

"If the project is dead, I could branch it on my GitHub with the SC and Max versions and maintain it..."
@Pierre Alexandre Tremblay - not dead but certainly been sleeping :)
Am happy to go with what you prefer here P.A.. The straight port is complete but most recent version could do with a polish - am happy to get that into some kind of shape, the rest is up to you.
We all know forks are generally bad...

A larger task that we got stuck on was working out best practice to share the wider lib (quite small, no more than 8 classes in total) - perhaps something for our small but mighty crew to consider (if anyone has any time?).

Finally, can I say what a brilliant project this was/is and huge thanks & respect to all involved.

J.

On Fri, 16 Jul 2021 at 08:39, Pierre Alexandre Tremblay <tremblap@gmail.com> wrote:
ipoke~ is definitely implemented. Julian Brooks was partly in charge to make it happen, and Katja did the job I think:

https://puredata.info/Members/ipoke/

If the project is dead, I could branch it on my GitHub with the SC and Max versions and maintain it...

https://github.com/tremblap

> On 15 Jul 2021, at 21:15, Peter P. <peterparker@fastmail.com> wrote:
>
> Hi list,
>
> hope you are fine!
>
> I am trying to build a variable speed looper which can change its
> reading and writing speed by the same factor. How could this be done? It
> seems there is no object that allows writing to a table (or delay line)
> at fractional speed.
>
> There is some discussion about [tabrwrite4~] or [ipoke~] in the list
> archives, but it seems it never led somewhere near an implementation,
> unless I am missing something.
>
> Could it work by placing order-forced [tabwrite~] and [tabread~] into a
> resampled subpatch perhaps? It would not allow seemlessly variable
> speed if it worked at all...
>
> thanks for all ideas/pointers!
> 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