Re: [PD] readsf re-blocked up-sampled

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

Re: [PD] readsf re-blocked up-sampled

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

Re: [PD] readsf re-blocked up-sampled

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

Re: [PD] readsf re-blocked up-sampled

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

Re: [PD] readsf re-blocked up-sampled

If you are having glitches when reading a soundfile you should check what you are doing in your patch. [readsf~] is most likely to *not have* the blame for causing glitches. -- Mensaje telepatico asistido por maquinas. On 3/4/2018 5:53 PM, Marco Matteo Markidis wrote: I expect that using

Re: [PD] readsf re-blocked up-sampled

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 : > On 03/04/2018 06:39 PM, Marco Matteo Markidis wrote: > > Dear Miller, > > > > thank

Re: [PD] readsf re-blocked up-sampled

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

Re: [PD] readsf re-blocked up-sampled

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

Re: [PD] readsf re-blocked up-sampled

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

[PD] readsf re-blocked up-sampled

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