> 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. > 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." <[email protected]> > An: pd-list <[email protected]> > 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 > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
