In my head the point is: is it usefull to use a [readsf~] in a up-sampled subpatch to avoid audio dropout? My idea was to up-sampling and re-blocking a subpatch with [readsf~] and pass signal using [outlet~] to the main canvas. In this way [readsf~] has a larger blocksize read and it is called more often than the main canvas.

Best,
Marco

Ps. I think that the right word is audio dropout/audio interruption and not glitch. Sorry about that.

2018-03-04 22:19 GMT+01:00 IOhannes m zmölnig <zmoelnig@iem.at>:
On 03/04/2018 09:53 PM, Marco Matteo Markidis wrote:
> I expect that using [readsf~] in a re-blocked and up-sampled patch is
> usefull to have the same played back file but trying to avoid glitches.


sorry, i'm having trouble parsing that sentence.

anyhow, the sound you get *is* useful and the patch does what it
announces (that is: it has a subpatch with a different samplerate and
re-blocking).

if you want your soundfile to be played back at normal speed without
overlapping, then you play it in a non-reblocked and non-resampled canvas.
if you need to do something to that sound in a re-blocked and/or
re-sampled context, then you must send the audio-signal through
[inlet~]/[outlet~] which will do the re-sampling and re-blocking for you.

mgfdsar
IOhannes


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




--
Ho cambiato l'indirizzo email in mm.markidis@autistici.org . Se non è un problema, scrivimi a questo nuovo indirizzo email.

I changed my email address in mm.markidis@autistici.org . If it is ok for you, please write me to this new email address.