Dear Miller,

thank you for your patch. Anyway, until here I have been arrived. The point is that if you connect this [readsf~] to a [dac~] in the parent window it sounds 64-times higher and shorter. There is something that I am missing?

best Marco

2018-03-03 5:26 GMT+01:00 Miller Puckette msp@ucsd.edu:

Here's a quick test I made.. it seems to work OK:

#N canvas 575 153 544 389 10; #N canvas 167 97 714 533 sr 1; #X obj 142 58 block~ 4096 1 64; #X obj 92 251 osc~ 6400; #X obj 92 272 tabwrite~ foo; #X obj 186 243 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 319 228 readsf~; #X msg 317 146 open /tmp/test.wav; #X msg 343 197 start; #X obj 357 175 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 317 265 tabwrite~ foo; #X obj 427 307 timer; #X floatatom 427 328 5 0 0 0 - - -, f 5; #X obj 331 396 array define foo 1e+06; #X obj 92 342 soundfiler; #X msg 91 319 write /tmp/test.wav foo; #X msg 321 107 ; foo const 0; #X text 67 203 this is to make the soundfile /tmp/test.wav, f 23; #X text 324 55 Then clear out the array , open the file , and read it back in (1e6 points in 326 msec at 48K sample rate); #X connect 1 0 2 0; #X connect 3 0 2 0; #X connect 4 0 8 0; #X connect 4 1 9 1; #X connect 5 0 4 0; #X connect 6 0 4 0; #X connect 7 0 6 0; #X connect 7 0 8 0; #X connect 7 0 9 0; #X connect 9 0 10 0; #X connect 13 0 12 0; #X restore 226 209 pd sr;

cheers Miller

On Wed, Feb 28, 2018 at 12:12:49PM +0100, Amur Tet wrote:

...

Dear list,

I am trying to put a [readsf~] inside a sub re-blocked and up-sampled following a previous conversation[1], using [block~]. Anyway, I don't get the correct up-sampling factor. Assuming the patch at sr = 44100 hz, the same for the audio file, blocksize 64 samples, I tried various configurations with changing blocksize, overlap and up-sampling factor

but

...

without obtaining the wanted result. Any idea? Osx, Pd vanilla 47.1, quadriphonic soundfile.

Best, Marco Matteo Markidis

[1]: soundfiler alternative, https://www.mail-archive.com/ search?l=pd-list@lists.iem.at&q=subject:%22Re%5C%3A+%5C% 5BPD%5C%5D+soundfiler+alternative%5C%3F%22&o=newest&f=1

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

...

---

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

listinfo/pd-list

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.

2018-03-04 21:18 GMT+01:00 IOhannes m zmölnig zmoelnig@iem.at:

On 03/04/2018 06:39 PM, Marco Matteo Markidis wrote:

...

Dear Miller,

thank you for your patch. Anyway, until here I have been arrived. The

point

...

is that if you connect this [readsf~] to a [dac~] in the parent window it sounds 64-times higher and shorter. There is something that I am missing?

what do you expect? none of Pd's soundfile reading/writing objects do any resampling.

so if you play back a 22.05kHz soundfile in a patch running on 44.1kHz it will be played back at double speed (with double pitch and halt the duration).

gfmadsr IOhannes

---

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

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

Marco Matteo Markidis wrote:

In my head the point is: is it usefull to use a [readsf~] in a up-sampled subpatch to avoid audio dropout?

hi,

i'm really not sure if i understand what you're up to, but do you mean something like this (attached patches) ?

it's a modified [readsf~] that i use for playback of large files, and to sync audio and video (as it sends a time position message). you can set the blocksize with an argument (default is 128 samples)

best

oliver

I think the problem in reading soundfile from hard disk is to access to it, so reducing the accesses to hard disk can be a good practice to reduce audio interruption.

the idea to write in a table and then read it outside the up-sampled canvas sounds great, however it is not clear how to read chunks without every time close the file descriptor. could be an idea to add a method for read chunks without close the fd? or there is an alternative way without write code?

best, marco matteo markidis

2018-03-05 13:00 GMT+01:00 IOhannes m zmoelnig zmoelnig@iem.at:

On 2018-03-05 12:01, Marco Matteo Markidis wrote:

...

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.

i don't think i can follow the logic: how would having a larger blocksize that is called more often reduce audio dropouts?

if you care about reading larger chunks of the audio-file per block, you can just re-block the subpatch (without upsampling), and then the signal sent through [outlet~] will have the correct sample rate (and length, and pitch).

if you want to replace [soundfiler] with something that takes a little longer to read a soundfile into a table and therefore avoids dropouts (because it doesn't have to do all the work in a single DSP tick), you can use an upsampled (and probably reblocked) subpatch to read the soundfile with [readsf~], and write it into the table *inside* the re-blocked canvas. then access the data from outside (without re-sampling) and the data will be correct.

fgmasdr IOhannes

---

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

Thank you for your answer.

afaict, you misunderstood the idea.

Honestly, I was thinking simply to another idea. The point is to write with a [readsf~] into a table and then read the table with a [phasor~]. In this way one can simulate the [soundfiler], that is probably the first Miller's suggestion. Anyway, apart write the chunk-reader method, this can be done using a time-counter and a [switch~] in an [until] loop, in a blocking way, or writing a delay line and reading it, that is non-blocking. In this case, one has generally to accept the delay.

Best, Marco

2018-03-06 18:35 GMT+01:00 IOhannes m zmölnig zmoelnig@iem.at:

On 03/06/2018 03:25 PM, Marco Matteo Markidis wrote:

...

I think the problem in reading soundfile from hard disk is to access to

it,

obviously.

...

so reducing the accesses to hard disk can be a good practice to reduce audio interruption.

not necessarily. there is an operating system between Pd and the harddisk that does all kinds of caching and what not. also, if you have a spinning harddrive (as opposed to SSD) you will have much better performance if the disk keeps spinning (e.g. by polling it often).

...

the idea to write in a table and then read it outside the up-sampled

canvas

...

sounds great, however it is not clear how to read chunks without every

time

...

close the file descriptor. could be an idea to add a method for read

chunks

...

without close the fd? or there is an alternative way without write code?

afaict, you misunderstood the idea.

actually [readsf~] is quite good when it comes to reading soundfiles without blocking. the soundfile reading happends in a separate thread (so the main/audio thread will not be blocked) and you can specify a buffer time to give it enough time to seek the file.

but if you have a high bandwidth signal (e.g. a heavy multitrack recording) and the disk is just too slow to serve that data, then you can open and close file descriptors and juggle with blocks-to-read as you will, without being able to solve the problem.

so if tweaking the buffer size doesn't give you click-free play back, i doubt whether *anything* will help, short of getting a faster harddisk (RAMdisk, SSD, nvram).

gfdstr IOhannes

---

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