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
sugge
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 an
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 chunk
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 [
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
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 pa
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 [rea
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 you for your patch.
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
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 :
> H
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
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
configu
12 matches
Mail list logo