Pd-dev

pd-dev@lists.iem.at

2 participants
9620 discussions

Re: [PD-dev] call for discussion double-precision file extension
by Sebastian Shader 30 Mar '22

30 Mar '22

I wonder if anything should be considered for multi-instance support as well (externals compiled w/ PDINSTANCE) -seb Date: Tue, 29 Mar 2022 11:28:57 +0200 From: IOhannes m zmoelnig <zmoelnig(a)iem.at> To: Pd-dev(a)lists.iem.at Subject: [PD-dev] call for discussion double-precision file extension hi, TL;DR i'd like to suggest to use deken-specifiers as (optional) part of external filenames, in order to allow co-installability of externals of different OSs, architectures and floatsizes (and more to come). i would really love to push the double precision saga towards a (happy) end. we have been able to compile Pd for 64bit double precision numbers. there's even a double-precision variant available in the Debian "experimental" repositories (but who knows that?) *very* few people have started to provide externals (i counted: 4). afaict the biggest hurdle is that you can't really co-install single and double variants of the same external. since there are so few double-precision externals available, people who rely on externals will be forced to use single-precision Pd for some time. but since installing a double-precision external might overwrite an existing single-precision external (required in your other project), i understand why people are not exactly eager to do that.? one solution to this problem is to use different installation paths (e.g. ~/Documents/Pd/extra/ vs ~/Documents/Pd/extra64/). this doesn't play well with how deken currently works (as it stores the installation path globally (for all versions/variants of Pd). Lucas suggested to use different file extensions (a year ago...time flies), by inserting `.float64` (and possibly `.float32`) right before our known extension (so we get `foo.float64.m_amd64`) I didn't especially like this back then, but in the meantime i've come to the conclusion that it's probably the best way forward. however, i think that we might do better than just inserting a single `.float64`, and just unify the entire naming scheme to hold all the information we need. i'd therefore suggest to use the deken-specifier together with the native extension (for dynamic-link libraries), as a new extension. the "native extension for dynamic-link libraries" is typically defined on an OS level, and is something like ".dll" on Windows, ".dylib" on macOS and ".so" in the un*x world. the "deken-specifier" is what we use in deken packages to know that they contain binaries for your specific combination of CPU, OS and precision, and looks like "<OS>-<CPU>-<precision>", e.g. "Darwin-arm64-32" (which denotes a macOS binary ("Darwin") that runs on the M1 processor ("arm64") and uses single-precision numbers ("32" bits). this would give us filenames like "zexy.windows-amd64-32.dll" to keep things simple (and reduce the noise with -verbose), i would suggest to only allow lower case specifiers, and no arch variants (e.g. i386 for all x86_32 variants, and amd64 for all x86_64 variants) pros - using the system extension does not require us to invent our own extension for each new platform - system tools often use the file-extension to recognize the file type - deken-specifiers fully cover what we need to know (the problem space is the same for deken package files and externals: allow coexistence of files with multiple OS/arch/precision specs) - people can relate the files within a deken-package with the deken-package-filename - if we ever need to add a new parameter, the deken specifier and the externals are likely to be affected in a similar way, so we need to solve the problem only once. - it gets rid of the super-cryptic .<first-letter-of-the-os>_<cpu-arch> specifier (.o_ia64 anybody?) cons it shares the same (final) extensions as any support libraries. eg. "zexy.linux-amd64-32.so" + "libzexy.linux-amd64-32.so" (or even libzexy.linux-amd64-32.so.so, but I guess we don't want this) probably some more... instead of using the system extension for dynamic libraries, we might pick a general unified (final) extension, instead of the system ones, e.g. .pdx (but that is already taken) or .pd_external. but i think the less we invent ourselves, the better. Lucas had started a feature-request/discussion on this very topic a year ago, but it was dormant until now. https://github.com/pure-data/pure-data/issues/902 i would like to hear your opinion on this (here or at the issue tracker; or both), and eventually get this done. once this is solved, i will start to push Pd64 packages to the Debian repositories, so people can start to use it (without having to compile themselves). gfmsdr IOhannes ? just for the record: the biggest hurdle is of course that there is no double-precision download available right now... but that's a bit of an egg-hen problem.

2 1

Re: [PD-dev] pd 0.52-2 release plan
by Dan Wilcox 28 Mar '22

28 Mar '22

I think it's worth documenting it as a debuting tool, since that's what it's there for, as far as I can tell for Miller's response. > On Mar 24, 2022, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 2 > Date: Wed, 23 Mar 2022 17:39:36 -0300 > From: Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>> > To: Miller Puckette <msp(a)ucsd.edu <mailto:msp@ucsd.edu>> > Cc: pd-dev <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>> > Subject: Re: [PD-dev] pd 0.52-2 release plan > Message-ID: > <CAEAsFmhxRSpD5pLg0TBjxH08Ugo1zw7LQV2jv=+1arDdBA0m5w(a)mail.gmail.com <mailto:CAEAsFmhxRSpD5pLg0TBjxH08Ugo1zw7LQV2jv=+1arDdBA0m5w@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > Not sure it's worth documenting then... I should test and see it for myself > how it works so I actually get it. > > keeping it as a hidden feature for now. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

6 7

Re: [PD-dev] pd 0.52-2 release plan
by Sebastian Shader 24 Mar '22

24 Mar '22

I'm hoping to maybe get this pr bugfix in - fixing setting the canvas dirty flag for the font dialog/"font" message (fixes a partial regression I accidentally introduced in 0.51)https://github.com/pure-data/pure-data/pull/1591 thanks-seb >Date: Tue, 22 Mar 2022 08:50:51 -0700 >From: Miller Puckette <msp(a)ucsd.edu> >To: pd-dev(a)lists.iem.at >Subject: [PD-dev] pd 0.52-2 release plan >Message-ID: <YjnwW+D6a4VO7KMZ(a)ucsd.edu> >Content-Type: text/plain; charset=us-ascii > >to Pd dev - > >I'm hoping to put out a bugfix release, 0.52-2, into which I hope to keep >folding the develop branch (as it 'develops'), some other bug fixes >like https://github.com/pure-data/pure-data/pull/1566, and Alexandre's >documentation updates in whatever state it's in. > >Hoping to put out a 'test' today or tomorrow and a final one this weekend... > >Miller

1 0

pd 0.52-2 release plan
by Miller Puckette 23 Mar '22

23 Mar '22

to Pd dev - I'm hoping to put out a bugfix release, 0.52-2, into which I hope to keep folding the develop branch (as it 'develops'), some other bug fixes like https://github.com/pure-data/pure-data/pull/1566, and Alexandre's documentation updates in whatever state it's in. Hoping to put out a 'test' today or tomorrow and a final one this weekend... Miller

2 3

Re: [PD-dev] [PD] how to compile externals for apple silicon?
by Sebastian Shader 10 Mar '22

10 Mar '22

(replied to dev list, seems more appropriate)I think you can cross-compile for arm on intel if you have xcode 12.2 (which I believe requires MacOS 10.15 Catalina)https://developer.apple.com/documentation/apple-silicon/building-a… -seb -----Original Message----- From: Alexandre Torres Porres <porres(a)gmail.com> To: Pd-List <pd-list(a)lists.iem.at> Sent: Thu, Mar 10, 2022 11:29 am Subject: [PD] how to compile externals for apple silicon? In my next update of my libraries I wanna see if I can provide externals for M1 macs. I'm assuming I need an apple silicon computer for that, right? Since I don't, I'll ask for someone who has one to help me. Now, what's the next step, is pdlibbuilder ready for apple silicon macs? I see zexy is already provided for apple silicon by the way. cheers _______________________________________________ Pd-list(a)lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

2 2

getting rid of warning (incompatible integer to pointer conversion )
by Alexandre Torres Porres 23 Feb '22

23 Feb '22

Hi, I'm trying to get rid of all compilation warnings for my library but I'm stuck with this one. Is there a way to get rid of this or I'll just have to live with it? *warning: **incompatible integer to pointer conversion initializing 't_int *' (aka 'long *')* * with an expression of type 'int' [-Wint-conversion]* t_int*nblock = sp[0]->s_n; This is where it lives => https://github.com/porres/pd-else/blob/master/Classes/Source/chance~.c#L72 Thanks

4 5

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

Jump to page:

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