Pd-dev January 2022

pd-dev@lists.iem.at

9 participants
8 discussions

Doppler effect implementation
by Frodo Jedi 01 May '22

01 May '22

Hi all, I am searching for a Pd implementation of a doppler effect as realistic as possible. Any recommendations? Any patch/external already made and well tested? Cheers FJ

9 15

Why not use portaudio per default?
by Christof Ressi 24 Jan '22

24 Jan '22

Hi, here's a question that has been bugging me for quite a while: Why do we keep all those individual audio backends instead of just using portaudio everywhere? Are there any other reasons *besides* backwards compatibility with existing setups (saved preferences)? Currently we have the following backend (excluding the dummy backends): ALSA: s_audio_alsa.c ESD: s_audio_esd.c Jack: s_audio_jack.c MMIO: s_audio_mmio.c OSS: s_audio_oss.c portaudio: s_audio_pa.c --- Portaudio already supports all relevant audio backends (https://github.com/PortAudio/portaudio/tree/master/src/hostapi), so I don't see why we would have to provide our own implementations at all. It is just a big maintainance cost. Everytime we change something in the scheduling code, we have to make sure not to break any of those custom backends. Another advantage of using the portaudio "backend" is that you can always choose between the callback scheduler and the polling scheduler. I acknowledge that removing backends could break existing setups (because of saved audio preferences). Alternatively, we might actually keep them around for some time but hide them from the GUI. Either way, we could post a warning whenever we encounter an "audioapi" value other than "API_PORTAUDIO" in the preferences or any of the "-alsa", "-mmio", "-jack", "-oss" command line flags. So in practice people would just need to go to the audio settings, select the device again and save it. --- As a first step, we might compare our backend implementations with the portaudio implementations and see if there are any shortcomings. Regarding MMIO: the portaudio implementation works fine (tested with 1024 buffer size + 20 ms latency, both with and without "callbacks"). Generally, MMIO is very outdated and shouldn't be used in the first place. On Windows 7 and above, the best choice - besides ASIO - would be WASAPI. ESD (https://en.wikipedia.org/wiki/Enlightened_Sound_Daemon) is obsolete and can probably removed. Quote from "s_stuff.h": /*noideawhatthiswas,probablygonenow*/ This would only leave us with ALSA, Jack and OSS. To make comparisons, we would need to compile portaudio with ALSA, Jack and OSS support. Note that our portaudio folder doesn't include the "oss" and "jack" source folders. --- BTW, portaudio is now officially hosted on GitHub (https://github.com/PortAudio/portaudio) and development seems pretty active. In April 2021 they have finally released a new version (0.19.7) after 5 years! There is even a recent PR for pulseaudio support: https://github.com/PortAudio/portaudio/pull/336. This leads me to another question: should we include portaudio as a submodule? This would make it much easier to get the latest changes from upstream or send our own changes to upstream. Christof

5 12

Re: [PD-dev] Why not use portaudio per default?
by Dan Wilcox 24 Jan '22

24 Jan '22

It's actually relatively easy, but very verbose since running configure then runs the dependent lib configures as well. You just have to point the configure script to the subdirectory with another configure script. I have a couple projects which use autotools and rely on a couple custom libraries which also use autotools. You just pass the subdirectories via AC_CONFIG_SUBDIRS: https://github.com/danomatika/joyosc/blob/master/configure.ac#L85 <https://github.com/danomatika/joyosc/blob/master/configure.ac#L85> But in the end, I plan to simplify this layout and remove the need for this arrangement in the future. > On Jan 22, 2022, at 6:57 PM, pd-dev-request(a)lists.iem.at wrote: > > Since we build the sources ourselves, as you have noted, it probably > makes sense to keep them in our repo as well. I don't even know how to > properly integrate an automake project... -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

Re: [PD-dev] Why not use portaudio per default?
by Dan Wilcox 22 Jan '22

22 Jan '22

I agree with IOhannes in that it's an advantage to keep all of the sources together. Besides, we also only include those portaudio sources we actually need and build them manually, ie. as a static convince lib via autotools etc. When I helped with overhauling the autotools build some years ago, I kept that aspect as an expedient, but I think it's still a good practice in that Github, at the time, didn't actually check out the sources for submodules when downloading a zip or tarball via the online interface. I haven't checked, but this may have changed. In any case, best practice would be to general release tarballs using "make dist" but we currently don't do that, as far as I can tell. Also, Github isn't the only public git host around and even though it's been quite useful for us, we should be relatively flexible to move hosting whenever we need or want to. Being reliant on submodules for core dependencies makes this a little more brittle. I also agree with Christof that since portaudio development is much more active than it use to be, we should consider integrating newer stable versions as they come out. Note that I added update scripts which pull in the relevant portaudio or portmidi sources to automate this, ala: https://github.com/pure-data/pure-data/blob/master/portaudio/update.sh <https://github.com/pure-data/pure-data/blob/master/portaudio/update.sh> Note: We have integrated some custom patches for portmidi, ie. speed limiting etc, so it's a little more problematic to replace it as a submodule right now. > On Jan 21, 2022, at 8:53 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 2 > Date: Fri, 21 Jan 2022 18:22:48 +0100 > From: IOhannes m zm?lnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at>> > To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] Why not use portaudio per default? > Message-ID: <c46ce9b3-908e-917d-0c56-a8f580c7ab10(a)iem.at <mailto:c46ce9b3-908e-917d-0c56-a8f580c7ab10@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > On 1/21/22 14:59, Christof Ressi wrote: >> >> What about my proposition to include portaudio as a submodule > > in general i do not like git submodules. > > first of all they make problems when using 'git archive' to generate a > source tarball (e.g. when you create a 'git tag', GitHub offers you a > "Source Code" download which is created with this method). > this is often a problem for downstream packagers (e.g. for the Debian > packages) where crucial parts are missing from the source tarballs. > in the specific case of portaudio i don?t really mind, as in Debian we > are using the system-provided PortAudio (and explicitely do *not* use > the vendored version). > > 2nd, submodules do not allow for patching the vendored sources (e.g. we > *could* remove the annoying printout at Pa_Initialize() in our vendored > copy, but not with 'git submodule'). > otoh, we haven't really used this in the past, so we probably don't need > this anyhow. > > > so i really do not care. > what i do care about is that the portaudio backend implementation of Pd > remains (API-)compatible with released stable versions of PortAudio (and > ideally (API-)compatible with the version of portaudio shipped in major > linux distributions, esp. Debian) > > > >> now that it's officially on GitHub? > > this i don't really understand. what makes GitHub different from > BitBucket, GitLab, SourceForge or git.jackaudio.org <http://git.jackaudio.org/> with respect to 'git > submodule's? -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 4

pointer cast fix
by Dan Wilcox 21 Jan '22

21 Jan '22

I'd like to fix a few warnings but I want to double check the cast. The warnings come from creating object hex names from pointers. sys_vgui() doesn't trigger this warning, but sprintf() does. For example: ../src/x_text.c:101:31: warning: format specifies type 'unsigned long' but the argument has type 't_textbuf *' (aka 'struct _textbuf *') [-Wformat] sprintf(buf, ".x%lx", x); Would it be safe to do a cast to (unsigned long)? sprintf(buf, ".x%lx", (unsigned long)x); -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 2

Find external and install it in an custom folder does not work anymore in Pd 052.1on Debian ...
by Winfried Ritsch 12 Jan '22

12 Jan '22

First, good new year and thanks for 052.1 ! ... In previous version I got a file dialog and then I could store it e.g. in my "libs" folder within my project, which I also advised to my students sharing my projects, since they operate on different OS... and this is an easy task for most users. Now I get an error (see below) [1]. Since I do not want to make an Pd folder, since I work on many different (studio) computers and do not want to pollute the home directory with any Application folder like "Pd" [2] on every account ... So is this behavior intentional or an error ... so I will do an issue report. If intentional add an option to save the external into an chosen folder, since this is really important for distribution of Pd applications. mfg winfried [1] Error response: > couldn't open "/home/winfried/.local/lib/pd/extra/dekentmp.0": no such file > or directory couldn't open "/home/winfried/.local/lib/pd/extra/dekentmp.0": > no such file or directory> > while executing > > "open $downloadfilename w" > > (procedure "::deken::utilities::download_file" line 4) > invoked from within > > "::deken::utilities::download_file $URL $fullpkgfile > "::deken::download_progress""> > (procedure "::deken::clicked_link" line 16) > invoked from within > > "::deken::clicked_link > {http://puredata.info/Members/musil/software/iemgui/1.21-1/iemgui[v1.21-1]( > Darwin-amd64-32)(Darwin-i386-32)(Linux-amd64-32)(Wind..."> > (command bound to event) [2] Also I do not like the recent behaviour to be forced to choose default folders for externals installation, since also on headless computers when setup automatically, it cannot answer an file dialog on first startup, I do not know who had this idea or missed the discussion, to ask for one on first start of Pd and not as an option to add it later...

2 2

Re: [PD-dev] Find external and install it in an custom folder does not work anymore in Pd 052.1on Debian ...
by Dan Wilcox 07 Jan '22

07 Jan '22

> On Jan 6, 2022, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 2 > Date: Wed, 05 Jan 2022 20:19:07 +0100 > From: Winfried Ritsch <ritsch(a)iem.at <mailto:ritsch@iem.at>> > To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] Find external and install it in an custom folder > does not work anymore in Pd 052.1on Debian ... > Message-ID: <1975418.ThMadnPRZM@ras> > Content-Type: text/plain; charset="iso-8859-1" > > Thank you for the response. > > Am Mittwoch, 5. J?nner 2022, 13:07:38 CET schrieb Dan Wilcox: >>> On Jan 5, 2022, at 12:00 PM, pd-dev-request(a)lists.iem.at <mailto:pd-dev-request@lists.iem.at> wrote: >>> >>> Message: 1 >>> Date: Tue, 04 Jan 2022 20:58:02 +0100 >>> From: Winfried Ritsch <ritsch(a)iem.at <mailto:ritsch@iem.at> <mailto:ritsch@iem.at <mailto:ritsch@iem.at>>> >> >>> [1] Error response: >> That perhaps looks like a problem with deken itself. >> > It happens if Pd Document path is disabled and system path cleared. > > Not really a problem, but previous behaviour starting a file dialog did set the > external path, so we have to change this settings before using find > externals... anyway an error shouldnt happen. Sounds like a bug yes. Please open an issue, if there isn't one already. >>> [2] Also I do not like the recent behaviour to be forced to choose default >>> folders for externals installation, since also on headless computers when >>> setup automatically, it cannot answer an file dialog on first startup, I >>> do not know who had this idea or missed the discussion, to ask for one on >>> first start of Pd and not as an option to add it later... >> > Thanks, and one correction to above, not headless but mouseless and > keyboardless, on headless it does not ask for default folder. Ok good. I would be very remiss if Pd hung on a GUI plugin when running -nogui... >> A very long discussion went on, part of which ended up as a proposal: >> >> https://github.com/pure-data/pure-data/pull/152 <https://github.com/pure-data/pure-data/pull/152> >> <https://github.com/pure-data/pure-data/pull/152 <https://github.com/pure-data/pure-data/pull/152>> >> > Thank you for the hint, now I understand... I am too late for respones ;-). > > ... anyway I thought Pd is gentleware: respectful to environments, not > wolvesware which tend to leave their marks everywhere where they can ... > but maybe it's only us old hacker generation, the younger generation got used > to it. I'm not going to rehash the whole thing but I tried to find a compromise for both, even if it's not perfect. >> There is a key in the GUI settings for the Documents path which can be set >> to "DISABLED" to avoid triggering the initial dialog. This is what is set >> when you select No. >> > ok, so I can do on remote command: > $ mkdir -p ~/.config/Pd/org.puredata.pd.pd-gui > $ echo DISABLED > .config/Pd/org.puredata.pd.pd-gui/docspath.conf I don't know the details of the Linux conf handling, but that looks correct. For macOS, this would be the equivalent: $ defaults write org.puredata.pd.pd-gui docspath "DISABLED" >> Also, the documents directory handling is implemented as a plugin, so it >> could be deleted or renamed to avoid it entirely. >> > I will take a look in this, but better dont touch the pd distributions > packages.. Maybe we need to add a plugin override in general (-noplugin "docsdir") or a docspath override specifically, ala -nodocsdir? I tried to make sure if doesn't ask if the home directory is not available or not writable (ala readonly setups), but maybe there can be another hacker-friendly check? Logic is in the plugin init proc: https://github.com/pure-data/pure-data/blob/master/tcl/pd_docsdir.tcl#L40 <https://github.com/pure-data/pure-data/blob/master/tcl/pd_docsdir.tcl#L40> My original thinking was that if you didn't want the docspath handling, you'd just press No once and never see it again, however if you are working with more than a couple normal desktop installs, this can of course not be the case. > mfg winfried >> -------- >> Dan Wilcox >> @danomatika <http://twitter.com/danomatika <http://twitter.com/danomatika>> >> danomatika.com <http://danomatika.com/> <http://danomatika.com/ <http://danomatika.com/>> >> robotcowboy.com <http://robotcowboy.com/> <http://robotcowboy.com/ <http://robotcowboy.com/>> > > > -- > - ao.Univ.Prof. DI Winfried Ritsch > - ritsch(a)iem.at <mailto:ritsch@iem.at> - http://iem.at/ritsch <http://iem.at/ritsch> > - Institut fuer Elektronische Musik und Akustik > - University of Music and Dramatic Art Graz > - Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171 -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 2

Re: [PD-dev] Find external and install it in an custom folder does not work anymore in Pd 052.1on Debian ...
by Dan Wilcox 05 Jan '22

05 Jan '22

> On Jan 5, 2022, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 1 > Date: Tue, 04 Jan 2022 20:58:02 +0100 > From: Winfried Ritsch <ritsch(a)iem.at <mailto:ritsch@iem.at>> > > > [1] Error response: That perhaps looks like a problem with deken itself. > [2] Also I do not like the recent behaviour to be forced to choose default > folders for externals installation, since also on headless computers when > setup automatically, it cannot answer an file dialog on first startup, I do not > know who had this idea or missed the discussion, to ask for one on first start > of Pd and not as an option to add it later... A very long discussion went on, part of which ended up as a proposal: https://github.com/pure-data/pure-data/pull/152 <https://github.com/pure-data/pure-data/pull/152> There is a key in the GUI settings for the Documents path which can be set to "DISABLED" to avoid triggering the initial dialog. This is what is set when you select No. Also, the documents directory handling is implemented as a plugin, so it could be deleted or renamed to avoid it entirely. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

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 January 2022