[PD] variable speed tabwrite~?

[Matt Barber]

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 at gmail.com> wrote:

> Hi all,
>
> Yes, as stated -- ipoke~ is definitely implemented.
> @Peter P. <peterparker at fastmail.com> how you getting on with it? There's
> a more recent version too, with some additional classes and tests that
> @katja <katjavetter at gmail.com> implemented.
> There's also an experimental ipoke4~built that's not short of complete
> (with more input from Katja, @Matt Barber <brbrofsvl at gmail.com> & @Charles
> Z Henry <czhenry at gmail.com> ) 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 at xs4all.nl <fjkraan at 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 <tremblap at gmail.com> - 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 at 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 at 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 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/20210804/b10b0449/attachment.htm>