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