> I understand. So, are you saying the problem with not updating GUI
> widgets doesn't happen with smaller patches? It's specific to your large
patch?
Absolutely! It does not happen in small patches.
It seems like Pd takes a long time (sometimes over 5 seconds) for opening
the window.
TK/TCL
> I understand. So, are you saying the problem with not updating GUI
> widgets doesn't happen with smaller patches? It's specific to your large
patch?
Absolutely! It does not happen in small patches.
It seems like Pd takes a long time (sometimes over 5 seconds) for opening
the window.
TK/TCL
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
