Pd-dev

pd-dev@lists.iem.at

2 participants
9620 discussions

libpd search paths
by Joseph Larralde 16 Feb '19

16 Feb '19

Hi, A friend of mine wrote this libpd wrapper for nodejs (which is actually a work in progress) : https://github.com/ircam-jstools/node-libpd It's running fine on a pi3 I'm using ATM. Now I need to use some externals I wrote, and I can't get them to load properly. But, they're loading when I start my test patch using pd itself. Before diving into his wrapper code, I'd like to make sure I'm placing the externals in the right path. What makes me think it should be working is this page : https://github.com/libpd/libpd/wiki/misc And also the fact that in his code, he's calling the init() function from PdBase, which is itself calling the libpd_init() function. I tried putting the externals into /usr/local/lib/pd-externals, /usr/local/lib/pd/extra, /usr/lib/pd/extra and ~/.local/lib/pd/extra. But still no luck ... Can anyone confirm I'm not mistaken ? Cheers, Joseph

4 7

Re: [PD-dev] libpd search paths
by Dan Wilcox 15 Feb '19

15 Feb '19

A few things: 1. libpd does not use any paths, settings, audio/midi backends, etc from desktop pd. It is only the core and less than "pd without the gui." This is by design as it makes no assumptions about the environment since it can be running in all manner of places. This means it will only search paths relative to an opened patch and those added explicitly by llibpd_add_to_search_path(). 2. Loading an external, whether it was compiled against 0.47 or 0.49 should work as, largely, the pd API has not changed that much. 3. libpd needs to be built with -DHAVE_LIBDL in order to be able to load separate, precompiled externals. 4. Some environments do *not* allow loading dynamic libraries for legal/security reasons, ie. iOS. I don't this is the problem, but it's good to know... I image you're issue is more to do with 3. Message: 1 > Date: Wed, 13 Feb 2019 15:04:19 +0100 > From: Joseph Larralde <joseph.larralde(a)gmail.com> > To: Giulio Moro <giuliomoro(a)yahoo.it>, Lucas Cordiviola > <lucarda27(a)hotmail.com>, pd-dev <pd-dev(a)lists.iem.at> > Subject: Re: [PD-dev] libpd search paths > Message-ID: <2354c1c4-e6db-9143-1402-76dcd37b43a8(a)gmail.com> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Mmmh you might have found the clue ... > Actually I built the externals against pd version 0.49-0 and it makes > sense that they load properly with the same version. > node-libpd comes with an arm libpd binary which seems to come from an > older version of pd (added 1 year ago). > I can already tell that it's not an architecture issue because > everything is working on my pi : the addon is loading and running > abstractions when used in a node program, and pd is loading and running > my externals. > Only loading my externals from node-libpd doesn't work. > Still trying to get a local version of node-libpd to work ... then I'll > replace the libpd.so with one that I'll build from the latest version. > I can't see another explanation. > Do you know something about incompatibilities between different versions > of pd ? > The libpd.so used by the addon is probably not older than 0.47 > -- Dan Wilcox @danomatika danomatika.com robotcowboy.com

2 5

Re: [PD-dev] libpd search paths
by Joseph Larralde 13 Feb '19

13 Feb '19

Hi Giulio, Le 13/02/19 à 11:11, Giulio Moro a écrit : > That sounds like an interesting project, although I struggle to understand how it would be used. Yes it is :) Actually we are working on a project where we make an extensive use of nodejs for distributed local applications, so it's worth using this addon in our case (and that's the kind of scenario for which it was initially created). I must admit that for my own use, I'm only launching pd from a node server and then doing everything else in the patches ... (I was inspired to do so after trying out the Bela once, so thanks for the inspiration) > AFAIK, libpd does not search in any of the default Pd paths. It comes with a `libpd_add_to_search_path()` function that you should use to manually add the search paths. From the README of node-libpd, among the todos there is : > • re-enable addToSearchPath and clearSearchPath Thanks for explaining the path issue before I went crazy. You're right, this is written in the todos of the README, which is a bit minimalistic ... > So that is probably where the issue lies. In the meantime you can consider just copying or symlinking your externals to the current folder. Unfortunately, copying the external to the current folder didn't help, so I guess I'll have to modify the addon a bit to re-enable the addToSearchPath method and make a PR. From my experience of pd, I suspect this should be done at initialization time, so I might have to modify the addon's api to provide another json field in the init method instead. Does this sound right-minded ? Thanks, Joseph > > Giulio > > On Wednesday, 13 February 2019, 09:49:08 GMT, Joseph Larralde <joseph.larralde(a)gmail.com> wrote: > > Hi, > > A friend of mine wrote this libpd wrapper for nodejs (which is actually > a work in progress) : > https://github.com/ircam-jstools/node-libpd > It's running fine on a pi3 I'm using ATM. > > Now I need to use some externals I wrote, and I can't get them to load > properly. > But, they're loading when I start my test patch using pd itself. > > Before diving into his wrapper code, I'd like to make sure I'm placing > the externals in the right path. > What makes me think it should be working is this page : > https://github.com/libpd/libpd/wiki/misc > And also the fact that in his code, he's calling the init() function > from PdBase, which is itself calling the libpd_init() function. > > I tried putting the externals into /usr/local/lib/pd-externals, > /usr/local/lib/pd/extra, /usr/lib/pd/extra and ~/.local/lib/pd/extra. > But still no luck ... > > Can anyone confirm I'm not mistaken ? > > Cheers, > Joseph > > > > _______________________________________________ > Pd-dev mailing list > Pd-dev(a)lists.iem.at > https://lists.puredata.info/listinfo/pd-dev >

3 3

removing pd/bin/msvr*.dll from Pd/win
by IOhannes m zmölnig 28 Jan '19

28 Jan '19

hi, TL;DR: i'd like to suggest to remove the "msvcr90.dll" and " msvcrt.dll" files from the pd\bin\ folder of all (future) windows releases. rationale ========= # usage by Pd first of all, these files are not used by Pd at all. they are only provided as a courtesy for externals that happen to require a dyamically linked libc implementation but fail to provide one themselves. most likely this is a leftover from the days, where any dynamic dependencies of an external would only be looked up in the Pd\bin\ folder (and not in the folder of the external itself), making it impossible to ship externals in a self-contained folder. luckily, these days are gone. # incompatibility for whatever reasons (personally i blame redmont, but i might be biased), "msvcrt.dll" is not a well defined library. especially it does not guarantee any binary compatibility. in practice, the "msvcrt.dll" as shipped with Pd is *incompatible* with msvcrt.dll as used by mingw when compiling. (it might also be incompatible with a file of the same name shipped with the latest release of MS Visual Studio, but i haven't checked). that means: the provided msvcrt.dll simply will not work with any mingw-compiled external. if the # compiling i noticed that i cannot compile/link externals for windows/32bit using mingw, if their build-system uses autotools/libtool. the linking stage fails in catastrophic ways, only because the linker picks up the here's an example log-file of such a failed build: https://git.iem.at/pd/Gem/-/jobs/3230 <techdetails> it took me a while to figure out what went wrong, because pd-lib-builder based externals compile just fine. it turned out, that the difference was that pd-lib-builder would link against "${PDPATH}\bin\pd.dll" (that is: it uses the full path as the library file to link against) whereas libtool based builds would link against "pd.dll" and add "${PDPATH\bin\" to the library search path (the actual linker flags being "-L${PDPATH}\bin\ -l:pd.dll"). since explicit library search paths take precedence over built-ins, adding "-L${PDPATH}\bin\" would make the linker find the "msvcrt.dll" file in ${PDPATH}\bin\, which happens to be incompatible with mingw, and thus an error is raised. </techdetails> the *only* way i found to fix the linker flag, is by removing the "msvcrt.dll" file from ${PDPATH}\bin\ before starting the build-process. in practice i also removed the "msvcr90.dll" file. incidentally, there are no problem with the w64 version of Pd, as this ships 32bit versions of "msvcr*.dll", which will be ignored by the compiler/linker/runtimelinker, because of a non-matching architecture. # conclusion afaics, there are currently **no** benefits in shipping the msvcr*.dll files. however, they do create a number of issues. (and in the case of Pd/W64 they are of the wrong architecture anyhow) i don't see a reason to keep them. fgmdsar IOhannes

6 24

Code responsible for calling canvas_reselect
by Henri Augusto Bisognini 18 Jan '19

18 Jan '19

When i use PD (Win 7) i can select an object and hit Ctrl+Enter to start/stop editing that object's text. I can't seem to find the code responsible for that behavior. Runningpd with the debug flag i can see that the gui sends a "$canvasname reselect" message to the patch (which is bound to "canvas_reselect" in "g_editor.c"). I've tried searching "reselect" and "Return" (case sensitive) for all the sources, checked pd_bindings.tcl but could find it. Where and how exactly this reselect messages are sent from the gui? Cheers, Henri.

2 1

how to fix m4 unrecognized --gnu option on macos?
by Federico Camara Halac 18 Jan '19

18 Jan '19

Hello, I am having this issue trying to compile from git but can't wrap my heads around it. This is the issue: pure-data $ ./autogen.sh autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I m4/generated -I m4 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/m4: unrecognized option `--gnu' Try `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/m4 --help' for more information. autom4te: /usr/bin/m4 failed with exit status: 1 aclocal: error: echo failed with exit status: 1 autoreconf: aclocal failed with exit status: 1 I realize the problem must be with my current environment (I never had this problem before) but I can't figure out where or how to fix it. I tried checking if the problem is in m4, so I do: $ which m4 /usr/local/opt/m4/bin/m4 $ m4 --version m4 (GNU M4) 1.4.18 But, I also have: $ /usr/bin/m4 --version GNU M4 1.4.6 Which (i guess) it's the same as: $ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/m4 --version GNU M4 1.4.6 Any pointers on how I can fix this would be really appreciated! Cheers, fede

1 1

question about q8_sqrt
by Christof Ressi 21 Dec '18

21 Dec '18

Hi, I have a question about q8_sqrt (out of curiousity): in d_math.c, the exported functions q8_sqrt and q8_rsqrt are defined like that: t_float q8_rsqrt(t_float f0) { union { float f; long l; } u; u.f=f0; if (u.f < 0) return (0); else return (rsqrt_exptab[(u.l >> 23) & 0xff] * rsqrt_mantissatab[(u.l >> 13) & 0x3ff]); } t_float q8_sqrt(t_float f0) { union { float f; long l; } u; u.f=f0; if (u.f < 0) return (0); else return (u.f * rsqrt_exptab[(u.l >> 23) & 0xff] * rsqrt_mantissatab[(u.l >> 13) & 0x3ff]); } but the signal objects dont' simply use these functions but do this instead: // sigrsqrt_perform while (n--) { t_sample f = *in++; union { float f; long l; } u; u.f = f; if (f < 0) *out++ = 0; else { t_sample g = rsqrt_exptab[(u.l >> 23) & 0xff] * rsqrt_mantissatab[(u.l >> 13) & 0x3ff]; *out++ = 1.5 * g - 0.5 * g * g * g * f; } } // sigsqrt_perform while (n--) { t_sample f = *in++; union { float f; long l; } u; u.f = f; if (f < 0) *out++ = 0; else { t_sample g = rsqrt_exptab[(u.l >> 23) & 0xff] * rsqrt_mantissatab[(u.l >> 13) & 0x3ff]; *out++ = f * (1.5 * g - 0.5 * g * g * g * f); } } the last two versions strongly resemble the fast inverse sqrt from Quake: https://en.wikipedia.org/wiki/Fast_inverse_square_root. my understanding is that the function version only give the first approximation whereas the perform routines apply Newton's method (once). please correct me if I'm wrong. I guess the key difference is the first approximation: in Quake it's a magic number but in Pd there are two lookup tables. how do the lookup tables work and what's the advantage? Christof

1 0

HMM in PD
by Frodo Jedi 16 Dec '18

16 Dec '18

Hi all, is there any working implementation of the hidden markov model in pure data? Any recommendation? Anyone who is working on the same topic? Cheers FJ

4 8

Re: [PD-dev] [PD] Keyboard patching
by Henri Augusto Bisognini 02 Dec '18

02 Dec '18

On 11/24/18 6:41 PM, Henri Augusto Bisognini wrote: > Hi PD list! > > I have an idea for a "keyboard patching" feature for PD On 11/24/18 6:41 PM, IOhannes wrote: you might want to look for the ideas matju (mathieu bouchard) had about this back in the days (i remember a presentation at Pd~con in montreal, together with chun lee). Hi Thanks a lot for pointing that out. The article<http://artengine.ca/~catalogue-pd/18-Lee-Bouchard.pdf> contains a lot of interesting ideas. Also upon searching for the DesireData<http://artengine.ca/desiredata/> implementation he mentioned on a footnote and looking at the screenshot gallery you can see even more features than described in the article. Too bad the project seems abandoned since 2010 :( 1. I really like the console idea. Indeed it is something that would not stand in the way of newcommers but could be very very useful for experienced users. If you think about it, we kind of already can send commands to canvases by using [namecanvas] and the Message dialog heh. A console would send the commands to the right canvas for you. More on that below. 2. I don't like the 45 degrees/tile navigating method. It is not precise enough. In the current keyboard navigation prototype<https://www.youtube.com/watch?v=Zyhm40tj7bU> i've implemented the following: - There is a shortcut to displaying the object indexes on the screen. Then there is a "goto" dialog where you type the index of the object and it selects it for you. (DesireData could display the indexes too). Not only this is useful for this "goto" keyboard selection method (which allows navigating faster and to objects that are not in your connection path) but it can also make dynamic patching easier. Plus it might be useful for commands if we decide for a console. Like creating connections on the console you could use those indexes. Something like conn 10-3 -> 23-1 to connect the 3rd outlet of object #10 to the 1st inlet of object #23 3. DesireData implemented a "object class list" and an suggestion windows. We already have that in the "completion-plugin" (it's on deken. btw a new release is planned for the near future). I've been using it literally everyday and it saves me A LOT of typing. People seem to like it a lot, i even got some inboxes on FB talking about it. Also we had testers that said it works normally on Raspberry Pi :) 4. It would be nice if connection.mpeg<http://artengine.ca/desiredata/gallery/connection.mpeg> showed the keystrokes. But looks impressive. Cheers, Henri.

1 0

Sigmund~ error?
by Nicolas Danet 30 Nov '18

30 Nov '18

Hi list, In sigmund~.c line 228 / < https://github.com/pure-data/pure-data/blob/master/extra/sigmund%7E/sigmund… > Is that, int bin2 = (maxbin < bestindex + 50 ? bestindex + 50 : maxbin); should not be instead: int bin2 = (maxbin > bestindex + 50 ? bestindex + 50 : maxbin); I'm probably wrong, but in case, somebody could check?

3 4

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