[PD] More adventures in [file] land - spaces in paths

Hello Did anyone have problems with spaces in paths? If one uses the help to demonstrate, entering the path (don’t worry this is not my real path :) /User/pa/my\ hard\ disk/my\ files/test.pd One gets at the bottom: /User/pa/my\\\ hard\\\ disk/my\\\ files/text.pd === If I investigate the list

Re: [PD] More adventures in [file] land - spaces in paths

No, it's just a display problem: https://github.com/pure-data/pure-data/issues/1477 On 12.01.2022 11:04, Pierre Alexandre Tremblay wrote: Hello Did anyone have problems with spaces in paths? If one uses the help to demonstrate, entering the path (don’t worry this is not my real path :) /Use

Re: [PD] More adventures in [file] land - spaces in paths

No worries! Actually, your question really shows how the current behavior of symbol atoms can be confusing and why it needs to be fixed. On 12.01.2022 12:38, Pierre Alexandre Tremblay wrote: How did I miss that when I search for issues I don’t know. Sorry for the noise. p On 12 Jan 2022, at

Re: [PD] [deken] new feature : download a list of externals

Thanks Iohannes. I didn't see this feature. It could be a nice way for newbies. And I see on github/deken that some requests are similar. The ideal way I guess, could be to write "zexy cyclone iemlib" and download them in oneshot. I will check the github page. Best. j. - Mail original -

Re: [PD] irreversibly high CPU usage with 'use callbacks' (macOS)

Just another data point: I'm not able to reproduce this here: * macOS 10.15.7 * Pd 0.52-1-really * MacBook Pro 2016 Tested with CoreAudio and JACK Roman On Tue, 2022-01-11 at 23:43 +0100, Christof Ressi wrote: > Hi, > > I have noticed this myself just a few days ago (Pd 0.52-1-really,

[PD] Store data in memory more efficiently than in arrays

Hi Sometimes I stored byte data (lists of bytes) in arrays. IIRC, I read once in IRC that one value in a Pd-array requires not 4 bytes, but 8 bytes on 64-bit systems. Since storing plain bytes seems not such an uncommon use case for me, I wonder if it can be done more efficiently. Not that I ever

[PD] JACK and blocksize

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 deeply

Re: [PD] irreversibly high CPU usage with 'use callbacks' (macOS)

no such luck here… mac OS 11.6.2 Pd 0.52-1-really open test audio+midi patch + cpu load meter set core audio to 48kh / blocksize 64 /5ms activate callbacks, switch on audio = instant crash. log attached hans Process: pd [97091] Path: /Applications/Pd-0.52-1-reall

Re: [PD] JACK and blocksize

* 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 a

Re: [PD] Store data in memory more efficiently than in arrays

I read once in IRC that one value in a Pd-array requires not 4 bytes, but 8 bytes on 64-bit systems. Yes. Pd's graphical arrays (and Pd's data structure arrays in general) are implemented as a linear array of "words" (t_word). A "word" can hold one of several possible types. It is implemented as

Re: [PD] JACK and blocksize

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 ca

Re: [PD] JACK and blocksize

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 (and

Re: [PD] JACK and blocksize

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

Re: [PD] JACK and blocksize

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 m

[PD] Arbitrary buffer sizes in pd, libpd

Apparently some applications on some OSes allow the user to set any buffer size in their audio settings. Sometimes the buffer size will be a slider to set any value small to large. One user of our VST3 plugin running libpd inside complained about sporadic crackles and discontinuities in the au

Re: [PD] JACK and blocksize

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 still

Re: [PD] Arbitrary buffer sizes in pd, libpd

It never even occurred to me to even test other buffer sizes than 64, 128, 512, 1024. Never assume that hardware buffer sizes are a power-of-2! There are even some built-in sound cards that *only* run on a single fixed weird buffer size. Conversely, never assume that all audio processing