Pd-dev April 2024

pd-dev@lists.iem.at

11 participants
8 discussions

Pd running on external scheduler changed
by Lucas Cordiviola 02 May '24

02 May '24

Hi, I'm working with some new feature of pdvst~ (https://git.nubegris.com.ar/lucarda/pdvst-0.52/compare/master...sq-fudi) this runs Pd via external scheduler "vstscheduler.dll" I hit some strange issue with current Pd (Merge branch 'scheduler_fix' 2bea249) this message no longer works ---------- ; pd dsp 1; ---------- while this one works [dsp 1( | [s pd] is not something I changed in pdvst~. Is something that only exhibits with the newest Pd. I can live with it but may be this is some "peak of iceberg" ? -- -- Mensaje telepatico asistido por maquinas.

3 7

Re: [PD-dev] threads
by Christof Ressi 24 Apr '24

24 Apr '24

(taking it back to the list) > > So, just to be clear, are you actually saying that PD's audio > internals *are* multi-threaded? Of course they are! Otherwise we wouldn't need the lockfree ringbuffer :) > The only occurrences I find in (0.53.1) of pthread_create() are in > d_fft_fftsg.c and d_soundfile.c. Where and how is the audio thread > created? How many audio threads are there? The audio thread is created implicitly by the audio backend. Typically, there is only a single audio callback and thus only a single "audio thread" per application. However, an application may create additional helper threads to spread DSP computation across multiple course. This is done by most modern DAWs. Another example would be Supernova, the alternative SuperCollider server by Tim Blechmann.) Christof

7 15

Re: [PD-dev] threads
by Dan Wilcox 15 Apr '24

15 Apr '24

It's the implementation used by libpd for passing messages between the audio thread to the various hooks. It is also used in the libpd Obj-C PdAudioUnit for buffering samples sample rate conversion is happening and the buffer size is inconsistent. If it was broken in some way, we would have heard about it over the last 10+ years or so. I trust the guy who wrote it (Peter Brinkmann) but it is admittedly older code now and I only updated to C atomics in a cursory manner via the macros. If y'all have thoughts/suggestions on improvement, please open an issue (or better a PR) on the libpd Github repo. > On Apr 11, 2024, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > As an aside: is the code in z_ringbuffer.{c,h} considered trustworthy? I > note that the other code in PD appears to use the sys_ringbuffer* API, > which seems to be built on the PA ringbuffer. I ask because I had some > problems with z_ringbuffer.c and after a code read, there are some bits > which look sketchy enough to me that I decided to stop using it. -------- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

Re: [PD-dev] Multiple audio devices?
by Dan Wilcox 13 Apr '24

13 Apr '24

I think the preference on macOS is to let the system do it via Aggregate Device. I'm not sure if PortAudio handles this as well on the platform. It might work but I'm sure using Audio MIDI Setup to do it is better. > On Apr 13, 2024, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 1 > Date: Fri, 12 Apr 2024 23:11:41 +0200 > From: Max <abonnements(a)revolwear.com <mailto:abonnements@revolwear.com>> > To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] Multiple audio devices? > Message-ID: <4d9ef88a-002e-46cc-9bea-d7a4a5cc27bb(a)revolwear.com <mailto:4d9ef88a-002e-46cc-9bea-d7a4a5cc27bb@revolwear.com>> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 12.04.24 21:59, Alexandre Torres Porres wrote: >> And I wonder why we can't do this on mac. It would be cool and would >> help me a lot > > I think the OS can do it on Mac (over a decade ago that I've used Macs, > but back then it was called "aggregate device" and you set up such meta > device which is composed of multiple soundcards. It exposes then the sum > of the inputs/outputs to the system). > > I have no idea about the rationale not to include that function in Pd on > Mac, but I assume it's better if the OS is doing it. From what I > understood Apple is doing resampling anyway to compensate for clock > drifts, just like pipewire does on Linux. > > https://support.apple.com/en-us/102171 -------- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Re: [PD-dev] threads
by Dan Wilcox 12 Apr '24

12 Apr '24

> I work with PD when I want to make music more than I want to do advanced CS. And then there's the question of the marginal utility of PD having its own implementation of a ringbuffer, but I will leave that for all of you who have dedicated far more time than I to the maintenance of this project. ...please don't let that stop you. I want to dedicate more time to making music myself! > To be more specific: the libpd ringbuffer uses atomic read-modify-write > operations (with dummy arguments) instead of atomic loads and stores. > Again, these are hacks from pre-C11 times. Unfortunately, the C11 > version follows this pattern instead of using the more appropriate > atomic_load[_explicit] and atomic_store_[explicit] functions. Also, it > implicitly uses the default memory ordering (memory_order_seq_cst) for > all atomic operations, which is much stronger than what we actually need. That's my fault. I did not have much time when I did that update, so I just found the equivalent functions without changing anything to be conservative. If you have suggestions for improvement, I am open to it. We can also ping Peter. -------- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

threads
by Caoimhe &co 11 Apr '24

11 Apr '24

Hi y'all - I'm about hip deep in what is probably an ill-advised project,and I have run into a situation where I am genuinely stumped. I am running a build of PD 0.53.1 and I notice that regardless of the audio back end I choose (between OSS, ALSA, and JACK, anyway) that I get at least four threads (more with JACK, but that may be my own fault) running PD on the latest AVLinux (based on MX, which is based on AntiX, which is based on Debian). What's up with that? What are those four threads all doing? I ask because I have only found the pthread_create that are in d_soundfile.c (reasonable) and d_fft_fftsq.c; and it certainly seems like none of those should be active just from starting up PD without even starting up the DSP loop. As an aside: is the code in z_ringbuffer.{c,h} considered trustworthy? I note that the other code in PD appears to use the sys_ringbuffer* API, which seems to be built on the PA ringbuffer. I ask because I had some problems with z_ringbuffer.c and after a code read, there are some bits which look sketchy enough to me that I decided to stop using it. d/c/&cet -- GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt

3 4

Any follow up on smspd, libsms (as in Spectral Modeling Synthesis) for realtime instrument ?
by Winfried Ritsch 10 Apr '24

10 Apr '24

Hello, Like presented in Conference on Digital Audio Effects (DAFx-09) 2009 [1] there was a library which can handle sms processing. Does anybody kbow of any follow ups or the like in the field of SMS for spectral synthesis ? Interested in SMS and of a Pd implementaion. mfg winfried [1] https://www.dafx.de/paper-archive/2009/papers/paper_79.pdf -- - ao.Univ.Prof. DI Winfried Ritsch - ritsch(a)iem.at - http://iem.at/ritsch - Institut fuer Elektronische Musik und Akustik, University of Music and Dramatic Art Graz - mobil: ++43-664-2439369 Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171 - Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171

3 5

emscripten support oops
by Miller Puckette 03 Apr '24

03 Apr '24

(specially to Claude Heiland and/or Dan Wilcox) - It looks like the code now in m_class_dispatcher* does "objectmaker" calls OK but misses some cases (and includes nonexistent ones) for plain messages. All plain messages are called with at least one pointer-sized argument that is the object to pass the message to, and no top of that may have up to five integer or floating-point arguments. So for instance, case 0x00 : (*(t_vfun00)(m->me_fun))(); break; and case 0x01 : (*(t_vfun01)(m->me_fun))(ad[0]); break; aren't needed but there should be a case 0x15: [...] etc. The number of cases is still 21. I think they are precisely the cases currently listed, each incremented by 16 with one leading integer argument. (symptom: clicking on a "pd" doesn't open it since canvas_click has 5 floating-point args :) I can dig in and try to fix this but I think one of you can do a more solid job of it than I could... cheers Miller

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev April 2024