On Bela we've been running with blocksize of 8 for a few years since 2016 and
then we moved to 16 samples per block around 2018 I think (in both cases
redefining the problematic constants). I think only in a couple of occasions
this caused an incompatibility with a couple of externals relying
This sounds reasonable. I have made a feature request on GitHub:
https://github.com/pure-data/pure-data/issues/1549
When I have time, I can make a PR. Or maybe someone else wants to do it?
Christof
On 16.01.2022 17:15, Athos Bacchiocchi wrote:
I tried setting DEFSENDVS, DEFDELVS to 16 as
You can use camomile (github.com/pierreguillot/Camomile) to wrap Pd
inside a VST for 64-sample latency back and forth.
cheers
Miller
On Sun, Jan 16, 2022 at 05:38:34PM +0100, oliver wrote:
> >
> > As for the need for it, I would personally use it, I tuned my linux
> > system to run at 16
As for the need for it, I would personally use it, I tuned my linux
system to run at 16 samples but I cannot use such settings when I want
to run Pd (I can with Bitwig and Bespoke synth).
Sorry , a little off topic ...
how exactly did you achieve that ? could you provide some specs ?
(linux
I tried setting DEFSENDVS, DEFDELVS to 16 as well, and everything seems to
be working fine now.
> (I would not recommend doing this in practice, though.)
Why wouldn't you recommend it? (I am assuming you were referring to
changing the DEFSENDVS/DEFDELVS define values).
I agree that it would be
Hi Christof
On Sat, 2022-01-15 at 15:51 +0100, Christof Ressi wrote:
> > Oh, interesting. Haven't tried myself yet, but good to know that
> > many
> > patches wouldn't work. I can't get around using [receive~].
>
> Have you seen my last reply (
>
Oh, interesting. Haven't tried myself yet, but good to know that many
patches wouldn't work. I can't get around using [receive~].
Have you seen my last reply
(https://lists.puredata.info/pipermail/pd-list/2022-01/130716.html)? It
describes how to fix this. (I would not recommend doing this in
On Fri, 2022-01-14 at 23:17 +0100, Athos Bacchiocchi wrote:
> I was curious so I compiled pd-0.52-1 on linux, with DEFDACBLKSIZE
> set to 16.
> I set Jack up with buffer size 16, and run pd with jack backend.
>
> Most of the patches in the help browser works, but at least these
> objects fail to
The objects in "d_global.c" use their own constant DEFSENDVS (for
whatever reason) which you would have to change as well. Same for
DEFDELVS in "d_delay.c".
Christof
On 14.01.2022 23:17, Athos Bacchiocchi wrote:
I was curious so I compiled pd-0.52-1 on linux, with DEFDACBLKSIZE set
to 16.
I
I was curious so I compiled pd-0.52-1 on linux, with DEFDACBLKSIZE set to
16.
I set Jack up with buffer size 16, and run pd with jack backend.
Most of the patches in the help browser works, but at least these objects
fail to load:
sigcatch : unexpected vector size
throw~ : vector size mismatch
On 1/12/22 21:04, Roman Haefeli wrote:
I guess my question boils down to: Is it possible to make that a
configurable (at runtime) parameter? Would it be worthwhile feature
besides an assumingly lower latency in special cases?
i prepared a patch that did that in 2004 or so.
i don't think i
Hi
Thanks for your detailed explanations, Christof.
On Wed, 2022-01-12 at 16:13 +0100, Christof Ressi wrote:
>
> Generally, there is no way to get lower I/O latency than 64 samples
> in
> Pd without changing DEFDACBLKSIZE and recompiling.
I guess my question boils down to: Is it possible to
Sorry, I didn't check this myself, but can {block~] be used in a
top-level patch perhaps?
You can, but then you can't use [adc~] and [dac~]. Also, it wouldn't
solve the latency problem. Generally, reblocking to a *lower* block size
does not affect latency.
Hi Roman,
I wonder if the blocksize of 64 is deeply baked into Pd or if it could
theoretically be made configurable.
Pd's scheduler block size is a constant value (64 samples), defined as
DEFDACBLKSIZE in "s_stuff.h".
In theory, you can change the #define in "s_stuff.h" and recompile Pd
On Wed, 2022-01-12 at 15:28 +0100, Peter P. wrote:
> * Roman Haefeli [2022-01-12 15:08]:
> > Hey all
> >
> > Using callbacks is certainly interesting for low-latency
> > applications.
> > I noticed that JACK allows blocksizes below 64, namely 32 and 16.
> > However, those can only be used with
* Roman Haefeli [2022-01-12 15:08]:
> Hey all
>
> Using callbacks is certainly interesting for low-latency applications.
> I noticed that JACK allows blocksizes below 64, namely 32 and 16.
> However, those can only be used with callbacks disabled which means
> having to use an additional buffer
Hey all
Using callbacks is certainly interesting for low-latency applications.
I noticed that JACK allows blocksizes below 64, namely 32 and 16.
However, those can only be used with callbacks disabled which means
having to use an additional buffer again.
I wonder if the blocksize of 64 is
17 matches
Mail list logo
