[PD] tabread4~ interpolation revisited

Christof Ressi christof.ressi at gmx.at
Sun Jun 2 21:06:42 CEST 2019


thanks, will check it out! Christof

> Gesendet: Sonntag, 02. Juni 2019 um 19:25 Uhr
> Von: "cyrille henry" <ch at chnry.net>
> An: pd-list at lists.iem.at
> Betreff: Re: [PD] tabread4~ interpolation revisited
>
> 
> 
> Le 02/06/2019 à 17:46, Christof Ressi a écrit :
> >> bleeding from the interpolation artefacts audible in almost every second
> >> composition.
> > 
> > in your specific cases, are the artifacts really caused by the interpolation scheme or rather a product of indexing [tabread4~] with large floats (instead of using the second inlet)?
> > 
> > if it is really the interpolation, would you mind sharing sound examples? I'm genuinely curious.
> 
> you can have a look at tabread4c~ help file in nusmuk-audio lib (that can be installed thanks to deken)
> cheers
> Cyrille
> 
> > 
> >> At that time a lot of list members agreed that it might be great to
> >> switch interpolation algorithms in tabread4~ with an argument or
> >> message to the object.
> > 
> > Sounds like a nice feature!
> > 
> > Only tangentially related, but we might want to add a [rate( message for [tabplay~]. [tabplay~] can play arbitrarly large arrays without precision issues while with [tabread4~] this is only possible with complicated abstractions. I've made my personal version of [tabplay~] which allows to change the playback speed at message rate and I've found it *very* useful.
> > 
> > Christof
> > 
> >> Gesendet: Sonntag, 02. Juni 2019 um 16:58 Uhr
> >> Von: "Peter P." <peterparker at fastmail.com>
> >> An: pd-list <pd-list at iem.at>
> >> Betreff: [PD] tabread4~ interpolation revisited
> >>
> >> Hi list,
> >>
> >> having asked my students to compose pieces in Pd using audio data in
> >> tables and reading them via tabread4~ my ears are still slightly
> >> bleeding from the interpolation artefacts audible in almost every second
> >> composition. Surely, everyone likes to slow down playback and I think it
> >> should be possible without too many audible artifacts in Pd.
> >>
> >> There is this legendary discussion on this list
> >> https://lists.puredata.info/pipermail/pd-list/2008-06/062864.html
> >> after Cyrille kindly posted about his tabread4c~ external. He also
> >> pointed out more elaborate interpolation schemes such as in
> >> https://lists.puredata.info/pipermail/pd-list/2008-06/063221.html
> >> At that time a lot of list members agreed that it might be great to
> >> switch interpolation algorithms in tabread4~ with an argument or
> >> message to the object. As far as I can tell no additional interpolation
> >> got implemented until today. Am I correct here?
> >>
> >> The issue got briefly revisited two years later in 2010
> >> https://lists.puredata.info/pipermail/pd-list/2010-03/077232.html
> >> and raised by me again in 2015
> >> https://lists.puredata.info/pipermail/pd-list/2015-05/110312.html
> >> https://lists.puredata.info/pipermail/pd-list/2015-06/110751.html
> >> after which I switched to supercollider for the specific project I was
> >> working on at that time as it performed better at slow playback.
> >>
> >> What could be a possible way to get slow playback from tables with less
> >> artifacts? (I am tempted to add "in 2019") ;)
> >>
> >> Thank you for all ideas and comments!
> >> 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
> > 
> 
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>





More information about the Pd-list mailing list