Pd-dev October 2024

pd-dev@lists.iem.at

8 participants
11 discussions

Get declare -path path names without re-declare t_canvasenvironment
by Charles K. Neimog 22 Oct '24

22 Oct '24

Hi everyone! I need to get the paths declared using [declare -path <mypath>] to be able to add them to the Python search path when using the py4pd object. There is some way to get it? I found solutions on github, but all then redefine t_canvasenvironment. Then they do something like this: t_canvasenvironment *e = canvas_getenv(x->canvas); for (int i = 0; 1; i++) { const char *path_elem = namelist_get(e->ce_searchpath, i); if (!path_elem) { break; } } But this don't seems pretty good 🙃. There is some less hacky way? Thank you! ________________________ Charles K. Neimog | https://charlesneimog.github.io/ | Universidade de São Paulo

2 1

do we need a [pd META] subpatch in the documentation?
by Alexandre Torres Porres 17 Oct '24

17 Oct '24

Hi, I opened an issue about this in https://github.com/pure-data/pddp/issues/255 hopefully others can contribute to the discussion. cheers

1 0

sigmund update, was #include "config.h" in m_private_utils.h needed?
by Dan Wilcox 11 Oct '24

11 Oct '24

(Please don't hijack threads, make a new one. ...and yes, I did this recently and I should not have. 🙈) > On Oct 10, 2024, at 7:31 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 4 > Date: Thu, 10 Oct 2024 14:30:59 -0300 > From: Alexandre <porres(a)gmail.com <mailto:porres@gmail.com>> > Subject: [PD-dev] Re: #include "config.h" in m_private_utils.h needed? > To: Miller Puckette <mpuckette(a)cloud.ucsd.edu <mailto:mpuckette@cloud.ucsd.edu>> > Cc: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Message-ID: > <CAEAsFmj5aEgXGhHBdyC12Kj=6him0t0v9UitTZu0+gwZvi-MSw(a)mail.gmail.com <mailto:CAEAsFmj5aEgXGhHBdyC12Kj=6him0t0v9UitTZu0+gwZvi-MSw@mail.gmail.com>> > Content-Type: multipart/alternative; > boundary="000000000000917c80062422bcef" > > Em qui., 10 de out. de 2024 às 13:01, Miller Puckette < > mpuckette(a)cloud.ucsd.edu <mailto:mpuckette@cloud.ucsd.edu>> escreveu: > >> OK, if nobody objects I'll cut out the offending lines and call it >> 0.55-2test1. >> > > I've been in private conversation with Shahrokh about fixing some bugs in > expr and improving it a bit. See if he has anything to contribute now in > the very short term. > > Now for my so called "objection". Well, I just have an issue that I'd like > to bring to your attention :) which is this fix for [sigmund~] --> > https://github.com/pure-data/pure-data/pull/2445 and it's actually > something we also have to fix in the documentation, and that I don't really > understand how it works. I think it'd be good to also take care of this for > 0.55-2 > > cheers -------- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 2

Re: #include "config.h" in m_private_utils.h needed?
by Miller Puckette 11 Oct '24

11 Oct '24

[snip] and CCing to dev again ... OK, then can we just omit the #include config.h from m_private_utils.h ? (If we do that I don't have to try to figure out in what wierd corner case it's causing trouble :) > having said all that, Pd is not currently using config.h at all. > > g,adsr > IOhannes

3 4

#include "config.h" in m_private_utils.h needed?
by Miller Puckette 10 Oct '24

10 Oct '24

I heard from an ESPD tester that compiling ESPD sometimes fails because (for some reason) HAVE_CONFIG_H is defined by the complicated ESP compile chain but there's no "config.h" in the Pd sources so this fails: #ifdef HAVE_CONFIG_H /* autotools might put all the HAVE_... defines into "config.h" */ # include "config.h" #endif It seems a bit fragile anyway... is there a way to make the test more stringent? Perhaps require that some other symbol be defined by hand before pulling in "config.h", and/or having some way to specify what directory to look for config.h in? In the meantime I already have to patch the Pd sources slightly to get ESPD to compile so I can work around this if I have to. thanks Miller

3 2

Re: #include "config.h" in m_private_utils.h needed?
by Dan Wilcox 09 Oct '24

09 Oct '24

I assume you're building via a custom Makefile and not Autools (configure)? If so, why not generate a dummy config.h in your makefile? I agree with IOhannes: this is standard operating procedure for auto tools projects and, in fact, I use the config.h pattern in other, non configure projects myself. > On Oct 9, 2024, at 7:21 PM, pd-dev-request(a)lists.iem.at wrote: > > > Message: 4 > Date: Wed, 9 Oct 2024 08:44:33 -0500 > From: Miller Puckette <mpuckette(a)cloud.ucsd.edu <mailto:mpuckette@cloud.ucsd.edu>> > Subject: [PD-dev] #include "config.h" in m_private_utils.h needed? > To: pd-dev <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>> > Message-ID: <dbbf85f8-a1d7-4937-83fb-7a6176b9be31(a)cloud.ucsd.edu <mailto:dbbf85f8-a1d7-4937-83fb-7a6176b9be31@cloud.ucsd.edu>> > Content-Type: text/plain; charset=UTF-8; format=flowed > > I heard from an ESPD tester that compiling ESPD sometimes fails because > (for some reason) HAVE_CONFIG_H is defined by the complicated ESP > compile chain but there's no "config.h" in the Pd sources so this fails: > > #ifdef HAVE_CONFIG_H > /* autotools might put all the HAVE_... defines into "config.h" */ > # include "config.h" > #endif > > It seems a bit fragile anyway... is there a way to make the test more > stringent? Perhaps require that some other symbol be defined by hand > before pulling in "config.h", and/or having some way to specify what > directory to look for config.h in? > > In the meantime I already have to patch the Pd sources slightly to get > ESPD to compile so I can work around this if I have to. > > thanks > > Miller -------- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

puredata jack audio crashes using pipewire-jack with more than 15 channels under Linux/Debian
by Winfried Ritsch 09 Oct '24

09 Oct '24

Hello, Using Debian bookworm backport puredata and pipewire-audio and pipewire-jack backports, it crashes with 16 channels, but not with 15 channel. To narrow down the problem, before bug issue it, anybody the same or only system specific ? Here the debug output: Here the gdb output: $ pd -version Pd-0.55.1 ("") compiled for Debian (0.55.1+ds-2~bpo12+1) on 2024/09/22 at 20:24:41 UTC $ gdb pd ... (gdb) run -jack -channels 16 Starting program: /usr/bin/pd -jack -channels 16 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Detaching after fork from child process 55024] [Detaching after fork from child process 55027] [New Thread 0x7ffff74a56c0 (LWP 55028)] [Thread 0x7ffff74a56c0 (LWP 55028) exited] [New Thread 0x7ffff74a56c0 (LWP 55029)] [New Thread 0x7ffff6ca46c0 (LWP 55030)] [New Thread 0x7ffff639f6c0 (LWP 55031)] double free or corruption (out) Thread 5 "data-loop.0" received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff639f6c0 (LWP 55031)] 0x00007ffff7be3e3c in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd... bt #0 0x00007ffff7be3e3c in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff7b94fb2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007ffff7b7f472 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x00007ffff7bd8430 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x00007ffff7bed7ba in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #5 0x00007ffff7bef820 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x00007ffff7bf1e9f in free () from /lib/x86_64-linux-gnu/libc.so.6 #7 0x000055555567ec3a in ?? () #8 0x00007ffff7d952c7 in ?? () from /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjack.so. 0 #9 0x00007ffff7faa44e in ?? () from /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa- support.so #10 0x00007ffff7a971b0 in ?? () from /lib/x86_64-linux-gnu/libpipewire-0.3.so.0 #11 0x00007ffff7be2144 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #12 0x00007ffff7c627dc in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) watchdog: signaling pd... watchdog: signaling pd... ... kernel: 6.1.0-26-amd64 mfg winfried -- - 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)

5 11

Re: puredata jack audio crashes using pipewire-jack with more than 15 channels under Linux/Debian
by Dan Wilcox 09 Oct '24

09 Oct '24

> On Oct 8, 2024, at 11:28 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 2 > Date: Tue, 8 Oct 2024 09:49:09 -0500 > From: Miller Puckette <mpuckette(a)cloud.ucsd.edu <mailto:mpuckette@cloud.ucsd.edu>> > Subject: [PD-dev] Re: puredata jack audio crashes using pipewire-jack > with more than 15 channels under Linux/Debian > To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Message-ID: <e30022b2-ccff-4b23-b03d-8fdcc7775f6f(a)cloud.ucsd.edu <mailto:e30022b2-ccff-4b23-b03d-8fdcc7775f6f@cloud.ucsd.edu>> > Content-Type: text/plain; charset=UTF-8; format=flowed > > This might be serious enough to warrant putting out 0.55-2. I would like a new bug fix this for the libpd fixes as well... -------- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Re: [PD] Re: Lua in pd
by Dan Wilcox 03 Oct '24

03 Oct '24

I don't agree that Lua version are that much different. The API is pretty stable. Funny, I've regularly updated Lua for my openFrameworks bindings, from 5.1 all the way to 5.4 over the years and have not had major issues. I think I am simply not using any real end case features to where it matters. So far SWIG is handling the bindings generation well enough and I do add whatever small shims are needed via macros, but so far that has only been on the C side. The Lua side has been stable for me. > On Oct 3, 2024, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > On Wednesday, October 2, 2024 at 11:39:30 AM CDT, Christof Ressi <info(a)christofressi.com <mailto:info@christofressi.com>> wrote: > On 02.10.2024 18:30, Timothy Schoen wrote: >> Currently, pdlua is not compatible with luaJIT, since it was updated >> to Lua 5.4 (and uses some of the new features internally). It's >> possible to port it back to luaJIT by taking out all the new Lua bits. >> >> Both have some advantages and disadvantages. But for me, regular Lua >> would win (but only by a small amount). The reason is: it's >> architecturally simpler, more mainstream, more widely used/tested, and >> (in my estimation) more likely to be maintained for a very long time. >> luaJIT is very fast, so I'm not opposed to it either. Having any kind >> of scripting for objects available at all is the most important thing >> here 🙂 > > If LuaJIT stopped working for whatever reason, we could still use > vanilla Lua 5.1 - which will continue to work as long as we have C > compilers :) Lua is a bit peculiar in that every minor version is really > a different language. Once you pick a Lua version, you typically don't > upgrade, unless there is some very compelling reason. > > Personally, I'm using Lua 5.3 and I would also tend towards Lua 5.3 or > 5.4. We just have to be aware that once we pick a version, we basically > have to stick with it because of backwards compatibility. > > Christof -------- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Re: [PD] Re: Lua in pd
by Sebastian Shader 03 Oct '24

03 Oct '24

Well, hopefully someday the allocations/processing/interpretation/compilation isn't happening on the audio thread :) I think JIT compilation shouldn't necessarily be shied away from given class/object creation isn't realtime-safe anyways, and how much slower is it actually? Imo JIT compilation to lower-level should be considered more, like for [expr~] or maybe some heavy-like patch compiler thing that can do some of what gen~ does. somewhat off-topic: there are also some cool compiled lua-inspired languages like terra and nelua (which I was thinking of switching to for the project I was using luajit/pdlua for anyways) -seb On Wednesday, October 2, 2024 at 11:39:30 AM CDT, Christof Ressi <info(a)christofressi.com> wrote: On 02.10.2024 18:30, Timothy Schoen wrote: > Currently, pdlua is not compatible with luaJIT, since it was updated > to Lua 5.4 (and uses some of the new features internally). It's > possible to port it back to luaJIT by taking out all the new Lua bits. > > Both have some advantages and disadvantages. But for me, regular Lua > would win (but only by a small amount). The reason is: it's > architecturally simpler, more mainstream, more widely used/tested, and > (in my estimation) more likely to be maintained for a very long time. > luaJIT is very fast, so I'm not opposed to it either. Having any kind > of scripting for objects available at all is the most important thing > here 🙂 If LuaJIT stopped working for whatever reason, we could still use vanilla Lua 5.1 - which will continue to work as long as we have C compilers :) Lua is a bit peculiar in that every minor version is really a different language. Once you pick a Lua version, you typically don't upgrade, unless there is some very compelling reason. Personally, I'm using Lua 5.3 and I would also tend towards Lua 5.3 or 5.4. We just have to be aware that once we pick a version, we basically have to stick with it because of backwards compatibility. Christof > > > Tim > > > On 02/10/2024 16:09, Sebastian Shader via Pd-list wrote: >> I know it's old but I think for lua in pd luaJit should be considered >> if adding a lua. >> Imo they took out a very powerful feature in setfenv after 5.1 anyways. >> >> Luajit was still working with pdlua last I checked. >> Plus pd messages only use floats. >> >> -Seb >> >> >> On Wednesday, October 2, 2024 at 05:27:03 AM CDT, Timothy Schoen >> <timschoen123(a)gmail.com> wrote: >> >> Yeah, +1 for pdlua for me! >> >> Here's a few more reasons I'd love to see this: >> >> * pdlua objects require vastly less boiler-plate code than >> C externals. Especially for signals and graphics, it takes care of >> all the hard parts and common pitfalls for you. >> >> * As a result, creating pdlua objects is much more >> beginner friendly, and experienced programmers are less likely to >> make mistakes. Not requiring compilation makes writing coded >> externals as accessible as abstractions are currently. >> >> * The biggest weakness for a project like pdlua is needing >> to be installed manually. This discourages people from directly >> uploading their Lua objects on Deken. Like porres said, ELSE now >> ships with pdlua just so that we can ship lua objects. It would be >> amazing if we could assume them to just work. >> >> * As you might know, Lua is very compact, it can be >> compiled by adding "onelua.c" to your sources, and it has no external >> dependencies. For ease of maintenance, it's as good at it gets. Lua >> is also fast for a scripting language. Seems like the perfect fit for >> pure-data. >> >> >> If you want a sample of the API, here's the documentation for pdlua >> graphics: >> https://agraef.github.io/pd-lua/tutorial/pd-lua-intro.html#graphics >> >> Tim >> >> >> >> >> On 02/10/2024 06:12, Alexandre wrote: >> >> >>> >>> >>> >>> Let me share Tim's thoughts he sent me via a chat about coding >>> externals in lua, which I think are a perfect sell. Compared to C >>> externals, lua externals: >>> * Encourages open-source, since the source code is the >>> object >>> * Works on every OS, architecture, pd floatsize, >>> multi-instance, all without needing recompilation >>> * You can easily modify objects if you want to >>> * GUIs are now much easier to write with Lua than with C >>> * Are guaranteed to keep working even if Pd's C API >>> changes, or Pd changes GUI framework >>> * Are guaranteed to work across Pd forks, as long as they >>> correctly implement the lua API >>> >>> >>> >>> >>> >>> >>> Em ter., 1 de out. de 2024 às 15:36, Alexandre <porres(a)gmail.com> >>> escreveu: >>> >>> >>>> Em seg., 30 de set. de 2024 às 16:59, Christof Ressi >>>> <info(a)christofressi.com> escreveu: >>>> >>>> >>>>>>>>> Thanks to Antoine for mentioning pdlua! I will need to >>>>>>>>> check it out. I have already seen people doing some very cool >>>>>>>>> stuff with it. Maybe they already have the perfect solution :) >>>>>>>>> >>>>>>>>> >>>>>>>> I'm also looking at pdlua, which might want to become the >>>>>>>> official way to make graphical externs AND to add scripting in >>>>>>>> a fundamental way to Pd :) >>>>>>>> >>>>>> +1 for an official scripting language! :) (I love Lua, BTW.) And >>>>>> yes, it would make lots of sense to leverage the scripting >>>>>> language to implement custom UIs! >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> +1k >>>> >>>> >>>> >>>> >>>> >>>> Yay, great to hear that! BTW, I remembered about this ticket we >>>> opened years ago inquiring about adding lua to Pd >>>> natively! https://github.com/pure-data/pure-data/issues/687 >>>> >>>> >>>> >>>> >>>> Now that Tim is doing great work for graphics, this would be even >>>> more awesome! And I wouldn't have to worry in shipping it in ELSE >>>> for some externals that already use it :) >>>> >>>> >>>> >>>> >>>> cheers >>>> >>>> >>>> >>> >>> >>> >>> >>> --- >>> pd-dev(a)lists.iem.at - the Pd developers' mailinglist >>> https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/WOQJIW3FBB… >>> >> >> --- >> pd-list(a)lists.iem.at - the Pure Data mailinglist >> https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/GG7IF7MWR… >> >> >> To unsubscribe send an email to pd-list-leave(a)lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> https://lists.iem.at/ >> >> --- >> pd-list(a)lists.iem.at - the Pure Data mailinglist >> https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/TJOTDRAY3… >> >> >> To unsubscribe send an email to pd-list-leave(a)lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> https://lists.iem.at/ > > --- > pd-list(a)lists.iem.at - the Pure Data mailinglist > https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/F6CWKKSQH… > > > To unsubscribe send an email to pd-list-leave(a)lists.iem.at mailing list > UNSUBSCRIBE and account-management -> https://lists.iem.at/ --- pd-list(a)lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/GY5ULQJGM… To unsubscribe send an email to pd-list-leave(a)lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/

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 October 2024