thanks, will check it out! Christof

Gesendet: Sonntag, 02. Juni 2019 um 19:25 Uhr Von: "cyrille henry" ch@chnry.net An: pd-list@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@fastmail.com An: pd-list pd-list@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@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

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

Le 03/06/2019 à 09:35, Lorenzo Sutton a écrit :

On 02/06/19 17:46, Christof Ressi wrote:

...

...

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.

Agreed (also, maybe some where using lossy data compressed files with low bit-rates as sources etc. ...)

Care to share some audio snippets?

please, have a look at tabread4c~ help file in nusmuk-audio since I tried to explain everything there.

Lorenzo

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

I have to apologize, yes the artifacts were produced by the indexing

I've thought so :-) Interpolation artifacts are *usually* very subtle while the indexing artifacts might be quite harsh.

will use the second inlet from now on.

note that zexy has an (undocumented) [tabread4~~] object where the second inlet works at audio rate. this is useful for doing (sub)sample-accurate granular synthesis on long tables.

Interesting! How do you do that? Would you mind sharing an example?

it's an external :-) I can add the logic to [tabplay~] and make a PR, maybe Miller is interested in this.

Christof

Gesendet: Montag, 03. Juni 2019 um 11:19 Uhr Von: "Peter P." peterparker@fastmail.com An: pd-list pd-list@iem.at Betreff: Re: [PD] tabread4~ interpolation revisited

Dear Christof, dear list,

• Christof Ressi christof.ressi@gmx.at [2019-06-02 17:46]:

...

...

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)?

I have to apologize, yes the artifacts were produced by the indexing indeed. It turned out that 90 seconds into a 120 seconds file at 44k1 would already be too much for tabread4~'s indexing. Sorry for the noise, will use the second inlet from now on. And make a promise to myself to write a wrapper around tabread4~

...

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.

Interesting! How do you do that? Would you mind sharing an example?

Thanks! Peter

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

Hi list,

I am playing around with pd/doc/3.examples/B16.long-varispeed.pd in order to see if I can write a wrapper abstraction around it. So far I have a very hard time to understand how to do it. Has anyone attempted this so far (apart from Miller having it on his dolist, see his reply from a few months below)?

Furthermore I just discovered that the example plays back the sine wave in the table at slightly different speed, hence pitch. I tried a playback speed of 294 samples/seconds and the two versions of playback sound a few hertz apart. Can anyone confirm this by setting the playback speed to 294 and listening to both versions in that patch either alternatingly or together (some beating should be audible)?

thanks, P

• Miller Puckette msp@ucsd.edu [2019-06-03 17:28]:

See also pd/doc/3.examples/B16.long-varispeed.pd which shows how you can index a long wavetable using only vanilla tabread4~. It's a bit clunky and needs to be put in an easy-to-use abstraction (on my dolist for someday).

On Mon, Jun 3, 2019 at 5:14 AM cyrille henry ch@chnry.net wrote:

Hello,

• When reading a file at slower speed, tabread4~ create audible artefact. tabred4c~ use the same algorithm but with small difference in the interpolation coefficient (tabread4c~ use very classic coefficient for audio interpolation. Miller use a coefficient set that minimize artefact from a mathematical pov. But put them in very audible place).

So, when using tabread4 object to read an audio file t low speed, replacing it with tabread4c~ is an easy solution to improve audio quality.

• When you want to speed up a file playback, aliasing appear. Some algorithm solve this problem is a good way but I'm not aware of any pd implementation yet.

Any interpolator function i(t) can be applied as an anti-aliasing interpolator g(t). With playback speed a > 1, g(t)=(1/a) * i(t/a)

You just have to make it longer and flatter. It's surprisingly simple and works--accomplishes filtering and interpolation in one step. The number of operations scales with playback speed, a, but you only apply the filtering at each sample it's needed.

There is probably no way to reduce the problem O(a) to something nice like O(log(a) ), but I still wonder. Without reducing the order of operations or bounding the speed, there are potentially bad cases that would hang the audio.

I had an implementation tabread4a~ and tested it on a 256-point table. I used the interpolation function i(t) from tabread4~ in order to have it be exactly the same output and cpu cost at a<=1. Worked just great (though I left unfinished some goals there). You could play the table on a sweep from 1x up to 128x speed and the partials just move right up to the Nyquist frequency and trail off.

The point of having tabread4~ is to have a cheap polynomial interpolator with no tables, but it just costs more in this situation. Should be changed to a table of interpolation function values if you want to apply the g(t) formula.

Since the interpolated value depend of the playback speed, I don't think it should be implemented in a tabread object but in a tabosc~ object (or a "multispeed_play" file) I made a tabosci~ (i for interpolated) that allow to oversample/filter the interpolation algorithm. I agree that this is the worst solution to remove aliasing, but I did never had time to implement a better algorithm. So, for now, you can use tabosci~ when you want to play a file at faster rate with reduced aliasing.

And I +1 with you for asking a correct Whittaker–Shannon interpolation object.

cheers Cyrille

Le 02/06/2019 à 16:58, Peter P. a écrit :

...

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@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